Fortryllede data

Nu kender jeg ikke jeres behov, men jeg kan snildt finde på nogle grunde til, hvorfor counter mode måtte være det rette valg for jer.

Har I overvejet Galois/Counter mode (GCM)? Det er i det store og hele som CTR, men regner undervejs sideløbende det authentication tag, som jeg kan gætte ud fra dit link, at I også bruger/har brug for.

Vedr. magien, så ja, det er en grundlæggende udfordring, og svaret plejer at være, at det er god ide at bruge løsninger, som har haft mange øjne på over længere tid, end selv at opfinde noget. Ikke godt, men det mindst ringe alternativ.

En forbedring af sikkerheden ved kryptering er først at kryptere med en algoritme og dernæst med en anden. Selv om en af algoritmerne skulle have en svaghed, så er sandsynligheden for at begge har en svaghed ved samme nøgle en del mindre. Og man skal selvfølgelig bruge lange nøgler.

Det giver selvfølgelig ikke fuld sikkerhed, men man skal overveje, hvor mange ressourcer en evt. modstander gider bruge på at bryde netop dine krypterede filer. Så med mindre der er mange penge (eller stor prestige) at hente i at afkode netop dine filer, så skal du nok ikke bekymre dig voldsomt.

Nationalmuseet har fået en del ødelagt - mindre omhu? jeg spørger mig selv om det er for meget - desværre er den nationale interesse for industri og opfindere så lille i forhold til en tilfældig 'kunstner'.

Et punkt mere med sikkerhed : brand. Men er enig tyveri bortkomst er det værste og her hjælper det at palcer edata fysisk et andet sted det hjælper også mod brand.

Hvordan opbevarer i nøglen?

Har I overvejet Galois/Counter mode (GCM)? Det er i det store og hele som CTR, men regner undervejs sideløbende det authentication tag, som jeg kan gætte ud fra dit link, at I også bruger/har brug for.

GCM er en af de modes Colin forklarer i linket hvorfor er mindre attraktiv end AES-CTR + HMAC. Colin har ret godt styr på alt hvad der handler om kryptering, så det kan anbefales at læse linket.

En forbedring af sikkerheden ved kryptering er først at kryptere med en algoritme og dernæst med en anden.

Kan du bevise det? Det lugter langt hen af "selv at opfinde noget" som Bjarne skriver er værre end at bruge noget"som har haft mange øjne på over længere tid". I dine opvejelser glemmer du også risikoen for at kombinationen er nem at bryde.

Jeg synes det er et godt spørgsmål.

Jeg kunne godt tænke mig nogle debat-indlæg til følgende: Antag p er en krypteringsalgoritme, og q er det modsatte. Lad T være klartekst, og K være krypteret udgave. Der er naturligvis en krypteringsnøgle, men den behøver jeg ikke tale om. Altså: K=p(T) og T=q(K) - det er jo det normale forløb. Det skal også gælde at K1 ikke lig K2, hvor K1=p(T1) og K2=p(T2) når T1 ikke lig T2.

Ved diverse afprøvninger kan p og q verificeres - præcis som PHK skriver. Altså ved T=q(p(T))

Ved at inspisere K ses en volapyk samling af tegn.

Spørgsmål, og er det ikke PHK's spørgsmål, hvad nu hvis der findes en algoritme r, hvor T=r(K) - altså helt uden at kende krypteringsnøglen ?

Jeg taler ikke om brute force - ala Enigma-brydningen - men om en (hemmelig) dekryptering, som virker uafhængig af krypteringsnøglen - altså en (bevidst) designsvaghed ved p ?

Hvis dette er rigtigt, muligt, så er løsningen vel åben source og mange nørder som borer i algoritmen p. Og det er nævnt ovenfor.

Hvis en sådan algoritme skulle kunne findes ville det kræve at hvis K = p(T1) , så findes der ikke noget T2 som ikke er lig T1 og hvor p'(T2) = K (hvor p' er p med en passende kryptonøgle).

Jeg er ikke bekendt med kryptosystemer der opfylder dette, og det vil nok endda være ganske svært at konstruere et sådant hvor dekryptering også er muligt (det er nærmest det modsatte af et hash).

Jeg går ud fra I har tænkt over hvordan data bliver sikret mod bitfejl på lagringsmedierne. Hvilke teknikker har i brugt? Kan Parchive [1] hjælpe?

[1] https://en.wikipedia.org/wiki/Parchive

Overveje hvorfor du tager backup off-site, eller brandkopi som man kaldte i gamle dage.

Så det du måske skulle fokusere på er om dansk dataforening kan bruge denne backup af arkivet.

Kort sagt kan den læses så man får et brugbart arkiv. Så måske skulle i lave en afprøvning end to end.

Backup er intet - restore er alt

Det virker som et godt alternativ - baseret på "attic" - med en masse forbedringer/fixes.. og BSD licens ;)

Kan du bevise det?

Nej. Lige så lidt som jeg (eller nogen anden) kan bevise, at en anerkendt krypteringsmetode er svær at bryde. Man kan kun henvise til, at det er mindst lige så svært som et velkendt problem, som antages svært (uden at nogen har kunnet bevise dette). Så jeg kan f.eks. henvise til, at bryde en dobbeltkryptering må være mindst lige så svært som at bryde de enkelte komponenter, med mindre de er hinandens inverse eller tæt beslægtet med hinandens inverse.

Og hvis vi antager, at begge metoder kun har få svage nøgler, og at nøgler meget sjældent er svage for begge metoder, så er kryptering med begge metoder med samme nøgle mindre sårbar overfor svagheder i nøglen end kryptering med kun en nøgle. Er antagelsen så rimelig? Der er fundet svage nøgler til en del kendte krypteringsalgoritmer, men de er meget specifikke for de enkelte algoritmer, så jeg vil umiddelbart antage, at antagelsen er rimelig. Noget bevis har jeg dog ikke.

Men moralen er: Der findes ikke beviser for at krypteringsalgoritmer faktisk er svære at bryde. Man kan bevise at en metode er nem at bryde, og man kan bevise, at der eksisterer svage nøgler, men man kan ikke bevise, at der ikke findes andre svage nøgler (med mindre man har vist at alle nøgler er svage).

Hvis du kun vil bruge kryptering, der er bevist svær, så er du henvist til one-time pads, som mig bekendt er den eneste beviseligt svære krypteringsmetode. Og her er krypteringsnøglen lige så lang som det samlede korpus af data, som du nogensinde vil kryptere,

Jeg skal ikke argumentere imod folk, som tydeligvis har foretaget et informeret valg, men blot påpege at krypteringen i GCM er en CTR mode kryptering (hvor counter starter ved 1 fremfor 0, fordi counter=0 output bruges til at beskytte authentication tag), så den har alle de samme fordele (dog med et venligt nik til argumentet om øget kompleksitet, vi er jo mennesker). Ellers ville jeg ikke have nævnt den, uden at kende jeres argumenter for at vælge CTR.

Fidusen ved GCM er at du slipper for to pass over data for at lave både "secrecy" og "authentication", men det er ikke nær så vigtigt for os som "KISS".

Et "selling point" ved authenticated encryption (AE/AEAD) er, at ved ikke at adskille kryptering og authentification, så gør man chosen ciphertext angreb betydeligt vanskeligere. Dog næppe jeres væsentligste bekymring.

Igen, ikke for at starte en diskussion med nogen, som har foretaget et informeret valg, men der kan jo være andre læsere (som også anbefales at læse det med småt omkring valg af IV ... :-) ).

Og hvis vi antager, at begge metoder kun har få svage nøgler, og at nøgler meget sjældent er svage for begge metoder, så er kryptering med begge metoder med samme nøgle mindre sårbar overfor svagheder i nøglen end kryptering med kun en nøgle.

Skal det ikke være to forskellige nøgler? Eksempelvis to 128 bit nøgler der kombineres til 256 bit. Ellers risikerer du at en svaghed i den yderste kryptering afslører den fælles nøgle, således at den inderste kryptering bliver irrelevant.

Sagen er så at AES256 teoretisk kan være stærkere end kombinationen af AES128 og en anden svagere algoritme.

@Tobias Kildetoft Ahhhhh, bekendt med ?

Min pointe var, at der netop, måske, var skjulte muligheder i kendte systemer ? Altså at en bruger, e.g. mindre kyndig end PHK, kommer til at vælge et sådant system i god tro.

@JanHesterberg Jeg er ikke helt sikker på hvad du mener. Det er i praksis meget nemt at vise at en algoritme som du beskriver ikke kan findes for et givet kryptosystem, da det blot vil være at dekryptere en streng med et par forskellige nøgler og se at du får noget forskelligt (men dette er selvfølgelig under den antagelse at krypteringsalgoritmen svarer til en bijektiv afbildning på mængden af mulige beskeder af en given længde. Hvis ikke ville det potentielt kræve nærmere analyse).

Det var kun for at provokere at jeg spurgte om du kunne bevise det. Jeg er fuldt ud klar over at det (stort set) aldrig er muligt at bevise noget om sikkerheden i kryptografiske algoritmer.

Jeg ønskede at provokere fordi det råd du gav gik stik imod hvad jeg opfatter som konventionel visdom: Brug én velkendt algoritme, implementeret af nogen der har forstand på det.

Det er netop risikoen for at den anden algoritme er (tæt beslægtet med) den inverse til den første algoritme og Baldurs pointer der gør at jeg aldrig ville drømme om at anvende mere end én algoritme.

@Tobias Kildetoft Tak for svar, som sikkert er det endelige svar. Jeg indrømmer, at det er på kanten af min forståelse - selvom jeg har læst nogle supplerende forklaringer.

MEN, når PHK beskriver tiltag fra NSA: Mig bekendt er det nærmeste der er forsøgt på det du beskriver NSA's forsøg på at svække en NIST standard ved at bruge "trojan" EC parametre.

Disse parametre så på alle måder OK ud for udenforstående, men de havde en skjult matematisk egenskab som, hvis man kendte til den, tillod en at finde de resterende parametre med triviel indsats. (Ikke helt Euclids algoritme, men lidt derhenad.)

så er det vel på niveau med mit spørgsmål - altså en skjult "egenskab", som gør brydning af kryptograferingen lettere / let.

Dobbelt-kryptering anvendes i stor stil blandt folk der har forstand på den slags, oftest for at implementere en "two-man-rule" solidt i nøglehåndteringen.

Den anvendelse havde jeg glemt - og hvis de involverede har forstand på hvad de laver kan jeg også se fordelene over et steup med halve nøgler.

Jeg tror dog vi er lidt ude over hvad datamuseum.dk har brug for.

Så jeg kan f.eks. henvise til, at bryde en dobbeltkryptering må være mindst lige så svært som at bryde de enkelte komponenter, med mindre de er hinandens inverse eller tæt beslægtet med hinandens inverse.

Den antagelse er forkert, hvis du bruger samme nøgle til begge. Du kan risikere at den yderste kryptering er elendig og afslører nøglen til din superfantastiske inderste kryptering. Alternativt kan du risikere at den inderste kryptering giver et output med f.eks. nogle headers der kan bruges til et known-plaintext-angreb mod den yderste (og så har du igen nøglen til den inderste).

Krypter meget gerne dobbelt, men lad være med at bruge samme nøgle.

Det er mig bekendt et problem med alle asymetriske algoritmer, at de basere sig på et eller andet matematisk problem hvor vi (endnu) ikke har fundet en smart genvej.

Det er korrekt. Der er asymmetriske krypteringer som er baseret på NP-hårde problemer, men det hjælper desværre ikke. NP-hårdt betyder bare at der findes mindst én krypteret besked som er svær at dekryptere uden nøglen... Det hjælper ikke meget hvis den besked du ønsker at sende ikke tilfældigvis er en af de svære.

Men for så vidt symmetriske algoritmer og pre-shared-key er der ingen genveje og det er et matematisk fastslået faktum.

Det er så vidt jeg ved ikke korrekt. Der er i al fald ingen beviser for at f.eks. AES er sikkert, kun for at specifikke angreb ikke virker mod den.

Det eneste som bevisligt er sikkert er one-time-pad. Desværre er OTP per definition ikke brugbar til backup.

Jeg ønskede at provokere fordi det råd du gav gik stik imod hvad jeg opfatter som konventionel visdom: Brug én velkendt algoritme, implementeret af nogen der har forstand på det.

Selv uden de andres argumenter omkring dobbeltkryptering, så er din argumentation stadigvæk forkert. En ordentlig krypteringsalgoritme har netop den egenskab at den er ligeglad med hvad der krypteres. Såfremt din argumentation var korrekt, så kunne jeg tage andres krypterede tekst og kryptere det en gang til og det skulle så hjælpe mig med at finde en nøgle.

Ovenstående naturligvis under den forudsætning at man ikke bruger samme nøgle til de to krypteringer. Men det ville også være ufatteligt dumt.

Kravet er dog netop at de to anvendte algoritmer ikke må være beslægtede og nogle gange indsættes der for en sikkerhed skyld et "whitening" lag imellem de to krypteringer.

Det kommer an på hvad man vil beskytte sig mod. Hvis det blot handler om at man ønsker at have to personer der begge skal låse op, så kan man sagtens kan bruge samme algoritme. Hvis man vil sikre sig mod at algoritmen brydes så har du selvfølgeligt ret.

Siden kerneudfordringen i princippet ikke er krypteringens gyldighed, men at sikre holderne af data ansvarsfrihed (som jeg læser det). Så kunne man fordele indholdet på to (eller flere) lokaliteter, på en måde som med rimelig sansynlighed ville sikre at een lokalitet ikke indeholdt inkriminerende data. En model ville være at lave en OTP som beskrevet og så gemme nøglen på een lokalitet sammen med en url til modparten og vice versa på en anden lokalitet. Data kunne i den forbindelse være krypteret for ekstra sikkerhed for ulæsbarhed, men umiddelbart synes det ikke nødvendigt, med mindre man også vil gøre det svært at afkode data i det tilfælde at begge lokaliteter blev kompromiterede, men det læser jeg ikke som værende den grundliggende udfordring(?) Det er selvfølgelig et ekstra lag ovenpå en simpel filoverførselsmodel, men umiddelbart en nogenlunde simpel løsning som holder den enkelte lokalitet fra fra at indeholde potentielt kriminel data.

Er det ikke "bare" et spørgsmål om at have nok lokaliteter? Selvfølgelig halveres antallet af komplette backups, med den løsningsmodel jeg foreslog (plus evt. større sansynlighed for datakorrumption).

Jeg var også ude i at overveje en RAID3 lignende model, evt med en OTP nøgle som en slags paritet, hvis det giver mening (jeg har ikke gennemtænkt den løsning så meget). I alle tilfælde er der vel en del inspiration at hente i RAID modellerne, ikke mindst med blik på katastrofesikring?

Nej.

Whitening laget beskytter netop også imod den tilfælde hvor de begge uafhængigt af hinanden er endt med samme kode.

Jo.

Eller nærmere, det kan sagtens være at nogen putter whitening laget ind af den grund, men det er den forkerte måde at løse problemet på.

Keyspace for AES256 er 2^256 ... hvis man vælger tilfældige nøgler baseret på tilstrækkelig entropi, så er risikoen for sammenfald uendelig lille (ja ... jeg ved godt at 2^-256 ikke er uendeligt småt).

Problemet opstår når man forsøger at aflede en 256 bit nøgle fra en 4 ciffer pinkode (ca. 13 bits entropi) eller et 10 tegns password (SWAG: 60 bits entropi). Så kan man få sammenfald. Løsningen er selvfølgeligt at finde en bedre metode til at aflede nøgler.

I øvrigt kan man sagtens ende med at whitening+ikke beslægtet crypto=crypto ... det er muligt i en verden hvor 2^-256 regnes som sandsynligt.

Men i øvrigt synes jeg dine tanker om storage er fornuftige. Selvfølgeligt skal I ikke ud i OTP, når krypteringen blot handler om at jeres backup "ejere" ikke skal kunne anklages for at besidde copyrighted information. I skal blot gøre jeres bedste for at sikre at nøgle og data ikke besiddes af den samme person.

Den antagelse er forkert, hvis du bruger samme nøgle til begge. Du kan risikere at den yderste kryptering er elendig og afslører nøglen til din superfantastiske inderste kryptering. Alternativt kan du risikere at den inderste kryptering giver et output med f.eks. nogle headers der kan bruges til et known-plaintext-angreb mod den yderste (og så har du igen nøglen til den inderste).

En kryptering, der indsætter headers, er ikke nogen god kryptering. Og hvis den gør, så er løsningen at man i andet trin krypterer alt andet end headeren, som man lader blive uændret (eller erstatter af tilfældig støj af samme længde). Dermed er der ikke noget, der kan afsløre, om man i første trin har gættet den rigtige nøgle: Resultatet af første trin (når evt. header er skåret fra) kan ikke adskilles fra tilfældig støj. Så selv om det yderste trin er en svag kryptering, så hjælper det ikke til at gætte nøglen -- helle ikke, selv om du kender dele af den oprindelige tekst.

Af samme grund er det en god ide at komprimere sine data, inden de krypteres. Komprimeret data er tættere på tilfældig støj end det oprindelige data, så det gør det sværere at angribe.

Skal det ikke være to forskellige nøgler?

Ideelt set, jo. Men det er normalt bedre at kryptere en gang med en lang nøgle end to gange med en halvt så lang nøgle. Ved at genbruge nøglen slipper man for at skulle huske/gemme en dobbelt så lang nøgle.

Nøgler genereres ofte ved at hashe et løsen, f.eks. kan en tekst hashes til en 64-bit nøgle. Da der typisk kun er 2-3 bit entropi per tegn i en almindelig tekst, skal man bruge tekster på over tyve tegn for at have en vis sikkerhed. Alternativt sørge for at blande både store og små bogstaver, cifre og specialtegn. Men det er i reglen bedre at kræve længere nøgler (https://xkcd.com/936/).

Så hvis du vil have to uafhængige 64-bit nøgler skal du bruge over fyrre tegn i dit løsen, hvor du ved at genbruge samme nøgle til to forskellige algoritmer kan nøjes med lidt over tyve tegn.

Når man dobbeltkrypterer er det i øvrigt almindeligt, at man efter den første kryptering roterer sin tekst med en halv bloklængde. Dermed "blander" man to blokke sammen, og får noget, der effektivt svarer til en længere bloklængde.

Nøgler genereres ofte ved at hashe et løsen, f.eks. kan en tekst hashes til en 64-bit nøgle. Da der typisk kun er 2-3 bit entropi per tegn i en almindelig tekst, skal man bruge tekster på over tyve tegn for at have en vis sikkerhed.

Det er en meget naiv tilgang til nøgle generering. Hvis du har et password på mere end 20 tegn, så er du nødt til at have en rytme i passwordet. Fx. ved at det er sammensat af ord (evt. med alle mulige mangling regler). Ingen kan huske et 20 tegns password hvor alle tegn er lige sandsynlige.

Det ved dem der måtte have en interesse i at knække din krypteringsnøgle. Derfor vil en klog kode-knækker ikke søge slavisk først gennem alle mulige passwords med 1 tegns længde, derefter 2 tegn, etc.

Hver gang en database med passwords lækkes da bliver dem der forsøger at knække passwords lidt dygtigere. De forstår lidt bedre hvordan mennesker opbygger passwords og deres søge algoritmer bliver lidt bedre

For krypteringsnøgler skal hele keyspace være lige sandsynligt. Det er det ikke hvis nøglen generes fra et password der er valgt af et menneske.

Af samme grund er det en god ide at komprimere sine data, inden de krypteres. Komprimeret data er tættere på tilfældig støj end det oprindelige data, så det gør det sværere at angribe.

Det lyder for mig som et udmærket logisk argument, men jeg synes at kunne huske der har været et par angreb mod HTTPS/TLS der relaterede til komprimering... så man skal som sædvanlig huske det samlede angrebsbillede :-)

Det siges at en voksen dansker har et ordforråd på over 50.000 ord og et barn på 5.000 ord. Hvis vi siger at du vælger mellem 4096 ord (12 bit) så giver 6 ord nok til 72 bit og 11 ord til 132 bit. Det er bare en sætning, hvor de trivielle ord naturligvis ikke tæller med.

Man kan ikke bruge OTP til backup, fordi man så skal have et sted at gemme den nøgle man bruger til backuppen.

Den kan ikke gemmes samme sted som de oprindelige data, for så ryger backuppen sammen med de oprindelige data. Den kan heller ikke gemmes sammen med backuppen, for så kan backuppen dekrypteres.

Ergo skal den gemmes et tredje sted, men det skal være et sted man stoler på, for ellers kan den bruges til at dekryptere backuppen der ligger det sted man ikke stoler på. Men hvis man stoler på stedet man gemmer OTP'en, så kunne man lige så godt bare lægge hele backuppen der og lade være med at kryptere.

Ergo, kryptering af backup giver kun mening hvis nøglen er (helst meget) mindre end backuppen.

Det er bare en sætning, hvor de trivielle ord naturligvis ikke tæller med.

Men hvis det er en sætning, så er ordenes hyppighed ikke den samme. Langt fra. Det er sammenligneligt med (men ikke det samme som) frekvensanalyse i traditionel cryptoanalyse. Men det er rigtigt at hvis man er ude i diceware så kan man komme langt. Men der er stadigvæk et stykke op til 256 bit nøgler som nu synes standard for AES.

Det er en meget naiv tilgang til nøgle generering. Hvis du har et password på mere end 20 tegn, så er du nødt til at have en rytme i passwordet. Fx. ved at det er sammensat af ord (evt. med alle mulige mangling regler). Ingen kan huske et 20 tegns password hvor alle tegn er lige sandsynlige.

Det er netop derfor, at jeg reducerede entropien til 2-3 bit per tegn. Det er det, der er almindeligt i tekster bestående af almindelige ord -- og også derfor at xkcd angiver ca. 44 bit entropi for 24 bogstaver tekst.

Hvis du kræver at alle tegn er lige sandsynlige, så vil små bogstaver alene give 4,7 bit entropi per tegn. Og så kan du for at få de 44 bits entropi, som xkcd-eksemplet angiver, nøjes med 9-10 tegn. Men 9-10 tilfældige bogstaver er der ingen der kan huske, og det er derfor xkcd-striben foreslå at man i stedet bruger mere end dobbelt så mange tegn, men bruger dem på en sådan måde, at mennesker kan huske dem, dog uden at konstruere sætninger, der kan findes i tekstkorpus. Derfor forslaget om at bruge fire mellemlange, almindelige, men urelaterede ord såsom "correct battery horse staple". Det giver 44 bit entropi ud fra antagelsen om, at der er mindst 2000 mellemlange almindelige ord, og de er tilfældigt valgt.

Det giver 44 bit entropi ud fra antagelsen om, at der er mindst 2000 mellemlange almindelige ord, og de er tilfældigt valgt.

Problemet er selvfølgeligt at vi gerne skulle et stykke over 100 bit (200 bits hvis man er bange for quantum-computers) for at hele diskussionen her i tråden om sikkerhed giver mening. Nu er vi pludseligt oppe på at man skal huske 10-20 tilfældige ord. Hvis man have fuld værdi af AES 256 så er vi helt oppe på 24 ord. Kan du huske 24 tilfældige ord i rækkefølge?

For hvis du er nødt til at skrive dem ned, så kan du ligeså godt bare skrive koden ned.

Problemet er selvfølgeligt at vi gerne skulle et stykke over 100 bit (200 bits hvis man er bange for quantum-computers) for at hele diskussionen her i tråden om sikkerhed giver mening. Nu er vi pludseligt oppe på at man skal huske 10-20 tilfældige ord. Hvis man have fuld værdi af AES 256 så er vi helt oppe på 24 ord. Kan du huske 24 tilfældige ord i rækkefølge?

Mig bekendt betragtes 64+ bit som upraktisk at brute force. Symmetrisk kryptering som AES er endvidere ikke nødvendigvis sårbart overfor kvantum-computere sådan som algoritmer baseret på primtal er.

Når mindst 128 bits anbefales til AES så er det fordi man har indregnet chancen for at fremmede statsmagter måske kender nogle tricks, der reducerer antallet af muligheder der skal prøves. Styrken er med andre ord mindre end 128 bit.

Men hvis det er en sætning, så er ordenes hyppighed ikke den samme. Langt fra.

Det har jeg som sådan allerede taget hensyn til ved ikke at regne med mit fulde ordforråd på 50.000 ord. Hvis Torben Mogensen bruger en sætning med fagtermer fra den videnskabelige artikel, han aldrig fik skrevet, så er chancerne for at en computer regner den ud ekstremt lille.

Mig bekendt betragtes 64+ bit som upraktisk at brute force. Symmetrisk kryptering som AES er endvidere ikke nødvendigvis sårbart overfor kvantum-computere sådan som algoritmer baseret på primtal er.

Der er ikke så meget info derude, men det er længe siden 56 bit DES kunne knækkes hurtigt. Siden har vi fået signifikant højere hastighed når det gælder single threaded execution. Vi har fået massiv parrallelisme i form af SIMD og GPU performance. Og vi har fået massive distribuerede computer systemer i form af cloud computing.

Alle ovenstående tiltag giver mindst 8 bit hver. Mindst (måske er single threaded performance ikke vokset helt så meget, men det kan de andre nemt opveje). Jeg vil mene at man i dag skal et stykke over 80-bit, men det hele handler selvfølgeligt om hvad man er villig til at betale for at knække koden. Hvor meget vil nogen betale for at knække dansk datamuseums kode sådan at de kan bevise at foreningen ligger inde med 30 år gammel copyrighted software?

Mht. kvante-computere så er det min klare forståelse at AES128 er sårbar men at løsningen blot er at gå til AES256. Modsat EC og RSA hvor hele kryptosystemet falder sammen med introduktionen af kvante-computere.

Det har jeg som sådan allerede taget hensyn til ved ikke at regne med mit fulde ordforråd på 50.000 ord. Hvis Torben Mogensen bruger en sætning med fagtermer fra den videnskabelige artikel, han aldrig fik skrevet, så er chancerne for at en computer regner den ud ekstremt lille.

Ordforrådet har kun betydning for hvor mange bits hvert ord giver samt hvor meget du selv kan huske. Jeg tror du vil opdage at sætningssammensætninger ikke er så specielle at det gør noget og hvis man fodrer en machine-learning algo med bunker af artikler fra internettet samt typiske variationer så er det ikke så specielt alligevel.

Og et eller andet sted skal mapningen fra fagtermer til integers stå. Enten er denne "offentlig" og så kan man tage højde for dette i knækningen (dvs. så kender vi fagtermerne) eller også er den "hemmelig" og i så fald kunne man lige så godt skrive koden ned i stedet.

Alle ovenstående tiltag giver mindst 8 bit hver.

Prøv at regne på. Lad os sige at vores ultra Xeon CPU kan arbejde på 1 million kombinationer i sekundet, dvs 1E6/s kombinationer. Er 80 bit er utilstrækkelig, dvs 2^80 = 1E24 kombinationer? Det giver en søgetid på 1E18 sekunder = 1E10 år.

Samme regnestykke med 64 bit giver mindst 10.000 år. Teknisk set ikke ubrydeligt med en cluster på 10.000 maskiner og et år til opgaven, men hvem vil ofre det på at komme til dine data? Mindes en tegning hvor de bruger en hammer til at få koden ud af manden.

AES er designet så at din CPU ikke bare smadrer igennem en kombination per clock.

Det er også værd at nævne muligheden for at gøre det meget dyrt at tjekke et password. Eksempelvis scrypt: https://en.m.wikipedia.org/wiki/Scrypt

Det kan eksempelvis konfigureres så at en moderne maskine skal bruge sekunder eller mere for at tjekke blot et enkelt password.

Mindes en tegning hvor de bruger en hammer til at få koden ud af manden.

Yeah, rubber-hose cryptanalysis er ofte ret effektivt - og natulirgivs er der en xkcd :)

Security

Prøv at regne på. Lad os sige at vores ultra Xeon CPU kan arbejde på 1 million kombinationer i sekundet, dvs 1E6/s kombinationer. Er 80 bit er utilstrækkelig, dvs 2^80 = 1E24 kombinationer? Det giver en søgetid på 1E18 sekunder = 1E10 år.

Din beregning holder ikke. Jeg så et eksempel hvor de kom ned på 7.59 cycles/byte. Det svarer til 121 cycles/block. Det var på en x64 med 128 bit XMM registre. Med en moderne Intel CPU med AVX er vi oppe på 512 bit registre. Det giver en 4x speedup ved yderligere parallel processering. Så er vi på ca. 30 cycles/block.

Hvis det kører på en 8x Intel Xeon Platinum med 56 kerner ved 3Ghz så er vi på 4E10/s. På en enkelt computer. Vi køber cloud kapasitet på 10000 maskiner. Så er vi på 4E14/s. Det giver ca. 60000 dage. Stadigvæk for meget men i nærheden (og som jeg skrev burde 80 bit være ok lige nu).

Jeg har ingen tal på hvor hurtigt det vil køre på GPU, men det bør skalere lineært med "vector-længden" på GPU'en. Basalt set er parallel cracking af AES nærmest skabt til GPU beregning. Hvis det ikke hurtigt nok så er custom hardware vejen.

Min pointe er at man godt kan ... det bliver bare dyrt.

Mindes en tegning hvor de bruger en hammer til at få koden ud af manden.

Ja. Men nu snakker vi kryptering. I øvrigt er det svært at forstille sig en copyright holder dukke op med et tæskehold der forsøger at tvinge koden ud med magt. Og det var det PHK ville bruge kryptering til.

Jeg har ingen tal på hvor hurtigt det vil køre på GPU, men det bør skalere lineært med "vector-længden" på GPU'en. Basalt set er parallel cracking af AES nærmest skabt til GPU beregning. Hvis det ikke hurtigt nok så er custom hardware vejen.

Det er vel kun hvis man ikke bruger en KDF og det bør man vel "altid" gøre? Jeg ved da at f.eks. LUKS2 som default bruger argon2i som er forholdsvis sløvt og "computational cost" kan justeres afhængig af ens trusselbillede/behov.

Min pointe er at man godt kan ... det bliver bare dyrt.

Jeg mener dine tal er dybt urealistiske men det er jo også lige meget.. hvordan vil cracke en scrypt der tunet til at tage en time per forsøg på en moderne cpu?

Din beregning holder ikke. Jeg så et eksempel hvor de kom ned på 7.59 cycles/byte. Det svarer til 121 cycles/block. Det var på en x64 med 128 bit XMM registre. Med en moderne Intel CPU med AVX er vi oppe på 512 bit registre. Det giver en 4x speedup ved yderligere parallel processering. Så er vi på ca. 30 cycles/block.

Du starter med at beregne det nye kodeord der skal testes. Det tager A clock cykler. Dernæst kører du den relevante hash algoritme for B clock cykler. Dernæst sætter du din AES op og gør den klar, det tager C clock cykler. Så kan du prøve at dekryptere en block, D clock cykler. Og endelig kan du vurdere om resultatet er plain text på E clock cykler.

Hvis vi nu bruger GPG som program, så er den stærkeste hash vi kan vælge SHA512. Aner ikke hvorfor de ikke har scrypt, det burde de virkelig af hensyn til netop det vi diskuttere her.

SHA512 kræver mindst 100 cyckler per byte for kort plain text på de hurtigste platforme og meget mere på andre: http://bench.cr.yp.to/results-hash.html

Vi snakker derfor mindst 2000 cykler bare for at køre hash funktionen på et 20 bytes kodeord.

I stedet for GPG medfølger der et lille utility fra scrypt:

baldur@DESKTOP-5F7IMRQ:~$ time scrypt enc -t 60 x.txt x.scr Please enter passphrase: Please confirm passphrase: real 0m53.230s user 0m46.297s sys 0m2.000s

Her tager det omkring 50 sekunder at teste bare ét password på min computer. Hvis det ikke er nok, så er det bare at skrive et større tal efter -t.

Scrypt ser ud til at kryptere med AES256.

Scrypt funktionen er ikke officielt valideret men bruges af mange krypto currencies. Man må derfor antage at den er blevet udsat for en del forsøg på angreb. Der er også en RFC: https://tools.ietf.org/html/rfc7914

Med scrypt giver det ikke mening at bruteforce kodeord med bare en medium styrke af kodeordet. Der er ikke en direkte kobling mellem styrken af kodeordet, målt i bits, og antal bits brugt til selve krypteringen (AES128 vs AES256).

Det har jeg som sådan allerede taget hensyn til ved ikke at regne med mit fulde ordforråd på 50.000 ord. Hvis Torben Mogensen bruger en sætning med fagtermer fra den videnskabelige artikel, han aldrig fik skrevet, så er chancerne for at en computer regner den ud ekstremt lille.

Tilsvarende er det en fordel at blande flere forskellige sprog, f.eks. "VraiBatteriPferdStaple" i stedet for "CorrectBatteryHorseStaple".

Det er vel kun hvis man ikke bruger en KDF og det bør man vel "altid" gøre?

Kompleksiteten af KDF metoden er afgørende. Det er vi enige om.

Scrypt funktionen er ikke officielt valideret men bruges af mange krypto currencies.

Jeg kender ikke detaljer om scrypt, men der er historier om bruteforce angreb på LUKS hvor man reducerer komplexiteten kraftigt.

Der mangler kryptoanalyse af denne type funktioner til KDF formål. I den forbindelse er cryptocurrency ikke så interessant. Crypto-minere har relativt kort tid til at finde en løsningen og gevinsten er ikke så stor. Hold det op mod fx. de danske myndigheders forsøg på at bryde krypteringen i Tvind-sagen hvor man forventede at kunne finde inkriminerende materiale. I den sag brugte man +20 mio. på efterforskning. Hvis gevinsten er stor nok, er der folk der er vil bruge ressourcer.

Mht. de forskellige KDF'er så synes modellen at være en forventning om at f(f(f(f(f(f(f(x)))))) er 6 gange dyrere end f(x). Det er det ikke nogen der har sandsynliggjort at det altid skulle være tilfældet (fx. hvis f(x)=x+1 så kan jeg konstruere en funktion g(x)=x+6). Det er ikke en metodik som er heftigy kryptoanalyseret.

Som jeg forstår det er der FPGA version af scrypt der er markant hurtigere. Men jeg medgiver at hvis man stoler på en KDF funktion, så kan man klare sig med et kortere password (eller hvis det man ønsker at beskytte ikke er specielt meget værd).

For lang tid siden stillede jeg i min uvidenhed et spørgsmål: kan en leverandør af kryptografering ikke indbygge en svaghed, sålede sta det krypterede K ser fornuftigt ud, men som aligevel tillader levetandøren selv at bryde kryptogtafwringen uden at kende nøglen ?

Jeg opfattede svaret således: det kunne ikke lade sig gøre - og aå bar ser en forklaring.

Men efter at have lyttet til DR TV torsdag x 2, så lyder det som om at netop det er lykkedes for CIA, så NSA med begrænset indsats kan bryde ind i meget solgt krytoudstyr. Kilden er Washington Post, så det er vist ret godt.

min konklusion: det hele bygger på tillid, der er ingen garantier.