Selvsikkert DTU-hold: Bruce Schneier bange for at tabe SHA-3-dyst
Den internationalt anerkendte sikkerhedsguru Bruce Schneier var fornyligt fremme med en opfordring til at stoppe konkurrencen om at finde en efterfølger til krypteringsstandarden SHA-2.
Som begrundelse for at vente med at udråbe vinderen af konkurrencen og dermed SHA-3-algoritmen har Schneier kort fortalt anført, at SHA-2 stadig klarer sig fint rent sikkerhedsmæssigt. Hans eget bud på SHA-3 er i øvrigt blandt de fem tilbageværende finalister i konkurrencen, hvor vinderen forventes at blive offentliggjort inden for kort tid.
Men Schneiers begrundelse for at sætte konkurrencen på pause giver professor ved Institut for Matematik ved Danmarks Tekniske Universitet Lars R. Knudsen ikke meget for. Han deltager på et hold hovedsageligt bestående af folk fra DTU i konkurrencen med et SHA-3-bud kaldet Grøstl. Ifølge Lars R. Knudsen har amerikanske National Institute of Standards and Technology, der står bag konkurrencen, i hvert fald tidligere meldt ud, at vinderen ville blive fundet i løbet af september.
»Schneier har nok indset, at han ikke vinder. Han kommer jo med udmeldingen mindre end en uge inden, vinderen skal offentliggøres, og efter konkurrencen har været i gang i omkring fem år,« siger Lars R. Knudsen og tilføjer:
»Det virker på os, som om han er bange for at tabe.«
Deltagerne i kryptokonkurrencen har gransket hinandens algoritmer på kryds og tværs for at finde eventuelle svagheder i dem. Og efterhånden er de oprindelige 64 SHA-3-bud nu indsnævret til de fem finalister.
I har set Schneiers algoritme, har han grund til at være bange?
»Narh, den er ikke dårlig, men den er ikke lige så god som vores,« siger Lars. R. Knudsen med et grin.
Læs mere om DTU-holdets bud på en SHA3-algoritme i morgen, fredag, på Version2's og Ingeniørens hjemmesider.
Kommentarer (13)
...den bedste efterfølger til SHA-2 krypteringsstandarden...
Der er nu ikke tale om krypteringsalgoritmer, men en-vejs hashingalgoritmer til fingerprinting.
»Narh, den er ikke dårlig, men den er ikke lige så god som vores,« siger Lars. R. Knudsen med et grin.
Hvorfor er jeres den bedste? Mere fremtidssikker? Færre kollisioner? Nemmere at implementere? Hurtigere?
-
4 -
0
Det siger sig selv at kryptografer ikke "trash-talker" hinanden, de "hash-talker" hinanden.
Det kunne være sjovt med et rap-battle:
"Yo momma so thick she thinks XOR is an S-box!"
"Oh yeah ? Yo momma things Grøstl is a kind of potato!"
:-)
-
19
-
1
Hurtigere?
Altså nogle gange er det en fordel når noget er langsommere, men jeg ved ikke om det er kriteriet. (ved login check kan man hash'e mange gange, for at det tager længere tid at brute-force)
I typiske tilfælde bruger Skein halvt så mange klok-cykler som Grøstl:
http://bench.cr.yp.to/results-sha3.html
Så Skein er hurtigere.
-
3
-
2
Ville det ikke være mere interessant at høre DTU's holdes svar på Schneiers kritik end bare høre den skyde Schneier motiver i skoene.
Er de uenige i at at behovet for SHA-3 ikke er så stort som antaget for fem år siden?
Er de uenige i at forbedringerne i hastighed og implementations-kompleksitet er små i forhold til en fortsat brug af SHA-512?
-
15
-
0
Altså nogle gange er det en fordel når noget er langsommere, men jeg ved ikke om det er kriteriet. (ved login check kan man hash'e mange gange, for at det tager længere tid at brute-force)
En hashingsalgoritmes mål er ikke at være langsom, da de bliver brugt til andet og mere end blot indenfor kryptering - hvorfor jeg også er lidt ude med riven mht. version2 der ser ud til at sætte lighedstegn imellem de to. Hovedingridiensen bag Git er f.eks. hashing, og jeg tror langt de fleste af os gerne vil have så hurtige SCM værktøj som muligt.
Skal man sikre noget login, synkroniserer man (blockingqueue) og/eller holder øje med antal loginforsøg (auditing).
-
7
-
0
En hashingsalgoritmes mål er ikke at være langsom, da de bliver brugt til andet og mere end blot indenfor kryptering - hvorfor jeg også er lidt ude med riven mht. version2 der ser ud til at sætte lighedstegn imellem de to.
Husk på, at selvom de to ting jo ikke "er ens", som du siger, så er der dog et vist overlap. Nogle hash-algoritmer er jo "kryptografisk sikre" og andre er ikke.
:o)
-
1
-
0
Skal man sikre noget login, synkroniserer man (blockingqueue) og/eller holder øje med antal loginforsøg (auditing).
Det hjælper vel ikke hvis "hackeren" har adgang til den hashede værdi, hvorimod en langsom algoritme eller gentaget brug gør det dyrere at bruteforce selv hvis man har adgang til den hashede værdi.
-
1
-
1
Det hjælper vel ikke hvis "hackeren" har adgang til den hashede værdi, hvorimod en langsom algoritme eller gentaget brug gør det dyrere at bruteforce selv hvis man har adgang til den hashede værdi.
Jeg har rigtigt svært ved at se idéen i at udvikle en algoritme, der har som egenskab, at den er langsom. Hvis man ønsker at kompensere for kraftigere hardware, så kører man den hurtige algoritme flere gange og opjusterer løbende antallet man bruger.
-
2
-
0
Husk på, at selvom de to ting jo ikke "er ens", som du siger, så er der dog et vist overlap. Nogle hash-algoritmer er jo "kryptografisk sikre" og andre er ikke.
Det har du selvf. ret i, jeg synes bare vi bør nævne forskellen. Der er mange der ikke kan kende forskel på de to.
Det hjælper vel ikke hvis "hackeren" har adgang til den hashede værdi, hvorimod en langsom algoritme eller gentaget brug gør det dyrere at bruteforce selv hvis man har adgang til den hashede værdi.
Selv en konstant faktor x100 p.g.a. hurtigere hardware, er jo stadig irrelevant i forhold til et NP/faktorielt problem. Svagheder i algoritmerne, der tillader at man kan fjerne effektive bits og/eller generere kollisioner, er langt mere brugbare for sådanne hackere.
Jeg har rigtigt svært ved at se idéen i at udvikle en algoritme, der har som egenskab, at den er langsom. Hvis man ønsker at kompensere for kraftigere hardware, så kører man den hurtige algoritme flere gange og opjusterer løbende antallet man bruger.
Sådan gjorde PHK i BSD, men det er jo en stakket frist - stadig kun en konstant faktor. Svarer lidt til i gamle dage, hvor en 486 PC var nødt til at blive udstyret med en turbo-knap, så man kunne sløve spil ned til ikke at eksekvere for hurtigt.
-
3
-
0
Jeg har rigtigt svært ved at se idéen i at udvikle en algoritme, der har som egenskab, at den er langsom. Hvis man ønsker at kompensere for kraftigere hardware, så kører man den hurtige algoritme flere gange og opjusterer løbende antallet man bruger.
Et eksempel på en algoritme hvor en asymptotisk nedre grænse er ønsket for køretiden, er BitCoin-minedrift, da man jo ønsker at mængden af mønter som findes konvergerer mod et konstant antal. Der er selvfølgelig forskel på en algoritme som bruger en lille smule længere tid, og en algoritme som bruger længere og længere tid.
-
0
-
0
Et eksempel på en algoritme hvor en asymptotisk nedre grænse er ønsket for køretiden, er BitCoin-minedrift, da man jo ønsker at mængden af mønter som findes konvergerer mod et konstant antal. Der er selvfølgelig forskel på en algoritme som bruger en lille smule længere tid, og en algoritme som bruger længere og længere tid.
Nu talte jeg jo om hashing-funktioner generelt - jeg vil ikke på nogen måde afvise, at andre scenarier kunne have andre krav. Derudover synes jeg ikke at se nogen modstrid i dit eksempel på hvad jeg skrev - at ønske en "langsom" algoritme er jo ikke det samme som at ønske en algoritme med en nedre grænse for køretid. Det er to forskellige ting.
-
1
-
0
at ønske en "langsom" algoritme er jo ikke det samme som at ønske en algoritme med en nedre grænse for køretid. Det er to forskellige ting.
Hvis jeg ønsker at min algoritme skal være ω(f) for en problemstilling som har løsninger der er Ω(f), ville jeg kalde min algoritme langsom. Men ja, som jeg også sagde, der er jo tale om to forskellige slags langsom.
-
0
-
0
Hvis jeg ønsker at min algoritme skal være ω(f) for en problemstilling som har løsninger der er Ω(f), ville jeg kalde min algoritme langsom. Men ja, som jeg også sagde, der er jo tale om to forskellige slags langsom.
I tilfældet med brute-force/dictionary-attack (som konteksten må være i denne artikel) kommer man vel væsentligt længere ved istedet at udvide dét state-space der skal afprøves (bits) frem for en ad-hoc gentagelse der så iøvrigt ikke længere er kompatibelt på tværs at systemer i.e. crypt() på FreeBSD != crypt() på OpenBSD.
Moore's lov formuleret som én ekstra bit pr. 18 måned bliver til 7 bits over et årti, eller en faktor lidt over 100. Det tager så 14½ år at eliminere 10bit, og dermed komme op over de 1000 MD5 iterationer PHK f.eks. kører til password hashing på FreeBSD.
Jeg kan kun gætte på at når man ikke bare udvider nøglen (hashen's størrelse dvs. SHA-2 istedet for MD5), så skyldes det at der, trods salt, ikke er nok entropi bag genereringen af denne?!
-
2
-
0
Tilføj kommentar
