Kryptere med lengre dekrypteringstid

[Anzure]

Jeg har laget et program som lar deg kryptere en fil, men det tar mye lengre tid å dekryptere filen.

Dette er et kommandolinje basert program, som jeg laget i Java.

Navn på GitHub biblioteket: Crypto-File-Safe

Dette var mest for moro skyld og læringsformål, og jeg er ingen ekspert på kryptografi.

Tror dere dette fungerer? Eller er det en enkel vei rundt?

 

Endret 19. juli 2022 av waremanu

[Thorbear]

Om jeg leser koden din riktig, så ber du brukeren angi antall sekunder som krypteringen skal ta, også gjør du X antall iterasjoner der du krypterer med RSA inntil tiden som er brukt overstiger det angitte antallet sekunder?

Det at dekryptering tar lengre tid enn kryptering er da bare en funksjon av RSA, og det du har lagt til er bare iterasjoner for å treffe en minstetid for kryptering? Forstår jeg det riktig?

I så fall er det en svakhet at du bruker samme nøkkel ved hver kryptering, så om en angriper skal knekke dette med bruteforce så trenger de bare å prøve 1 iterasjon med hver nøkkel inntil de finner riktig nøkkel, også kan de gjøre X iterasjoner med riktig nøkkel.

Den mer riktige måten å løse dette på er vel å begynne med en "benchmark" av maskinen der du varierer lengden på nøkkelen frem til det tar lang nok tid å kryptere én iterasjon, også krypterer med 1 iterasjon med den nøkkelen. Da tar det like lang tid for en angriper for hvert eneste forsøk som det tar en vanlig bruker å dekryptere med riktig nøkkel.

[Anzure]

Takk for innspillet. Tanken var at det skal ta lengre tid å dekryptere enn å kryptere, selv om du vet nøkkelen.

Slik at du kan bruke det som en slags tidssafe, og at passordkrypteringen ikke var hovedfokuset.

Tror du det er mulig å dekryptere RSA krypteringen betydelig raskere på en eller annen måte?

Eller er det en vei rundt RSA krypteringen som lar deg bruke mindre ressurser?

[Thorbear]

Jeg kan ikke nok om RSA til å si om det er noen snarveier man kan ta der, men på generell basis er det frarådet å gjøre iterert kryptering med mindre man har veldig god kjennskap til hvordan algoritmene fungerer, nettopp fordi det kan oppstå snarveier når samme algoritme brukes gjentatte ganger på samme data. Det finnes algoritmer som gjør nettopp dette, jeg kjenner mest til passord-hashing der, med bcrypt o.l. som gjør iterasjoner med én algoritme for at det skal ta lengre tid, men det er da gjerne laget av folk med kjennskap til algoritmen, og testet/analysert av veldig mange som har lett etter snarveier uten å finne dem.

[Ernie]

For å ta det først som sist: Jeg har ingen formell bakgrunn innenfor sikkerhet og kryptografi.

Hva er målet du ønsker å oppnå her? Selv om det er en viss korrelasjon, så er det feil å anta at tiden det tar å kryptere og dekryptere sier noe om hvor sikkert det er. Eksempelvis tar det like lang tid å teste ut 10 nøkler hvor det tar 10 sekunder å teste hver av de, og 100 nøkler hvor hver tar 1 sekund å teste.

God sikkerhet baseres på sikre nøkler og kjente, trygge algoritmer, ikke hjemmesnekrede løsninger. Hvis man lurer på hva man skal bruke så er https://cordis.europa.eu/docs/projects/cnect/6/216676/080/deliverables/002-DSPA20.pdf et godt startsted, selv om det nå snart er et tiår siden ECRYPT II ble publisert. Kan også legge til at kvantedatamaskiner er en stadig større trussel. Hvis man antar verst mulig projeksjon (ut fra kryptografisk sikkerhet), så er RSA relativt ubrukelig om bare et par år. Allerede nå så bør man derfor presse nøkkelstørrelsen opp så mye som mulig. Personlig anser jeg ikke RSA nøkler under 4096 bit som fremtidsrettet med en 10 års tidshorisont.

Når det gjelder koden så lurer jeg vel litt på hva som er hensikten her. Sikkerhet er aldri sterkere enn det svakeste leddet. I dette tilfellet så lagres nøkkelparet i en zip-fil med AES kryptering basert på et passord fra brukeren, samt at det lagres ukryptert på disk. Straks man får fingrene i de nøklene så er alle RSA operasjonene trivielle.

[Anzure]

For å beskytte filen brukes vanlig AES kryptering, den skal sikre innholdet mot uvedkommende som ikke har nøkkelen. I tillegg er det en RSA kryptering som skal forsinke tiden det tar å lese filen (den skal ikke sikre innholdet). Siden RSA krypteringen skal forsinke og ikke sikre, så er nøklene tilgjengelige fordi de ikke er hemmelige. Dette er bare en prototype og det er nok noen flere sikkerhetstiltak som kan legges til, men jeg vil jo håpe de fleste har TPM og BitLocker (eller lignende) nå til dags.

Formålet er at det skal ta mye lengre tid å lese filen enn det tar å låse filen, altså en slags tidslås. Jeg har ikke funnet andre algoritmer eller løsninger som kan gi 20-60x lengre dekrypteringstid enn krypteringstid, dermed måtte jeg lage en hjemmesnekra løsning. Dette kan f.eks. brukes til å kryptere nøkler for en kryptovaluta lommebok, slik at du vil bruke lengre tid på å åpne den, som nevnt en slags tidslås.

[Ernie]

7 hours ago, waremanu said:

For å beskytte filen brukes vanlig AES kryptering, den skal sikre innholdet mot uvedkommende som ikke har nøkkelen. I tillegg er det en RSA kryptering som skal forsinke tiden det tar å lese filen (den skal ikke sikre innholdet). Siden RSA krypteringen skal forsinke og ikke sikre, så er nøklene tilgjengelige fordi de ikke er hemmelige. Dette er bare en prototype og det er nok noen flere sikkerhetstiltak som kan legges til, men jeg vil jo håpe de fleste har TPM og BitLocker (eller lignende) nå til dags.

Formålet er at det skal ta mye lengre tid å lese filen enn det tar å låse filen, altså en slags tidslås. Jeg har ikke funnet andre algoritmer eller løsninger som kan gi 20-60x lengre dekrypteringstid enn krypteringstid, dermed måtte jeg lage en hjemmesnekra løsning. Dette kan f.eks. brukes til å kryptere nøkler for en kryptovaluta lommebok, slik at du vil bruke lengre tid på å åpne den, som nevnt en slags tidslås.

Okay, du sier tidslås, men hva ønsker du å oppnå med det? Hvilken beskyttende verdi har det å vente noen minutter i verste fall? Grunnen til at du ikke finner eksisterende algoritmer er jo nettopp det at dette neppe har noen som helst sikkerhetsmessig verdi. Hvis du setter opp AES korrekt med en sikker nøkkel, så tar det jo årevis å bryte det opp, iallefall inntil en stor nok kvantedatamaskin eksisterer. Så hva er det dette tilfører prosessen?

[Ernie]

Jeg ble litt nysgjerrig så jeg gravde litt ned i materien. https://www.gwern.net/Self-decrypting-files beskriver hvordan en faktisk tidslås er problematisk å implementere. Det som allikevel er interessant her er http://people.csail.mit.edu/rivest/RivestShamirWagner-timelock.pdf hvor man tvinger den som skal dekryptere til å gjennomføre en sekvensiell kalkulasjon av kvadrater. Det er noen åpenbare likhetstrekk med RSA, så dette kan fort være problematisk ift. kvantedatamaskiner, men for noen år til bør det holde vann.

[Ernie]

Rivest publiserte forøvrig en tidlås han beregnet ville ta 35 år å løse. Den inneholder også et enklere eksempel samt litt kode, så det er nok et nyttig startsted hvis du vil bruke det

http://people.csail.mit.edu/rivest/lcs35-puzzle-description.txt

[knutinh]

En reell tidslås ville være interessant.

Det er nok tryggere å putte dataene inn et romfartøy, så skyte det ut i en bane som streifer jorda om 4-10-100 år.

Å sende ut et slikt fartøy er dyrt nok. Å avskjære det med et annet fartøy når man må jobbe «mot» pull fra andre himmellegemer innbiller jeg meg (kan gjøres) nært usaklig.

-k