Dødsstøtet for SHA-1: Google har cracket mye brukt kryptoalgoritme

[Gjest Marius B. Jørgenrud]

Mye datakraft gikk med for å knekke den allerede utdaterte algoritmen.

Dødsstøtet for SHA-1: Google har cracket mye brukt kryptoalgoritme

[ATWindsor]

Det sies at to checksums aldri skal kollidere, men det kan man jo strengt tatt ikke sikre seg mot? (jeg skjønner at i dette tilfellet så er det ikke en tilfeldig kollisjon, så det er allikevel ett problem, men tenker på generell basis)

 

AtW

[MegaMann2]

Det sies at to checksums aldri skal kollidere, men det kan man jo strengt tatt ikke sikre seg mot? (jeg skjønner at i dette tilfellet så er det ikke en tilfeldig kollisjon, så det er allikevel ett problem, men tenker på generell basis)

 

AtW

Du har rett, det er ikke mulig å sikre seg mot at ikke to genererte hash strenger har lik verdi så lenge det finnes fler mulige inputs enn outputs. Siden det er uendelig mange inputs er det ikke mulig å sikre seg mot kollisjoner.

 

Derfor kaller man en hash funskjon som sikker om den er "collision resistant". Dette begrepet innebærer at det er så vannskelig å finne kollisjoner at det ikke er praktisk gjennomførbart.

 

Derfor har man fortsatt å videreutvikle SHA-1 og i dag er det SHA-2 som er i bruk av alle som bryr seg om sikkerhet. SHA-1 er ikke så utbredt som digi skal ha det til, men alle SHA-1 sertifikater burde vært byttet ut med SHA-2 for lenge siden. Motiverte nok angripere kan nå (og tidligere) forfalske sertifikatene bare de har nok tid og resursser slik Google beviser. Google gjør også disse angrepene for å rette blikket mot at SHA-1 har vært brekt i lengre tid, og for å øke fokuset på å få byttet ut disse gamle SHA-1 sertifikatene som fortsatt er i bruk noen steder.

 

Teknikker for å fremskaffe kollisjoner i SHA-1 ble funnet helt tilbake til 2005, men det har ikke vært praktisk gjennomførbart å utføre angrepene på bakgrunn av den enorme mengen regnekraft som skal til.

[ButterScotch]

Det sies at to checksums aldri skal kollidere, men det kan man jo strengt tatt ikke sikre seg mot? (jeg skjønner at i dette tilfellet så er det ikke en tilfeldig kollisjon, så det er allikevel ett problem, men tenker på generell basis)

 

AtW

 

Det er per definisjon umulig å garantere. Om du har n antall mulige hash, og n+1 antall ulike datasett, så må minst to ha samme hash.

 

Sikkerheten ligger blant annet i at det ikke skal være overkommelig å skape et datasett som har samme hash som et target (type passord-hash, f.eks.). Dette er et moving target, og SHA-1 har nå beviselig nådd sin tid.

[Gjest Slettet-Pqy3rC]

Det sies at to checksums aldri skal kollidere, men det kan man jo strengt tatt ikke sikre seg mot?

Nei. Men jo flere bits i hash resultatet, jo færre mulige kollisjoner. Hvilket jo er logisk nok (hver bit øker antall mulige hash'er).

Matematikken er basert på noenlunde like prinsipper i alle rutinene (MD4, MD5, SHA0, SHA1, SHA2, SHA3 etc).

 

Alle seriøse sertifikatutstedere har allerede gått over til sikrere hashalgoritmer som SHA-256 mener Presttun

SHA-256 er "populært brukt navn" på en av SHA-2 variantene. Det faktum at SHA-2 har flere varianter (hash lengder) har skapt en del forvirring, særlig fordi SHA-3 deler noen av de samme lengdene som SHA-2.

f.eks er SHA-224 (SHA2) og SHA3-224 (SHA3) er forskjellige beregninger, men gir samme hash lengde.

 

Jeg liker bedre begrepet SHA2-256.

 

Note;

SHA-2 har forresten størrelsesbegrensning på data det skal lages hash av (riktignok digert, men dog), noe SHA-3 ikke har. SHA-3 er liksom litt tilbake til MD5 igjen, men med større "state table" (i mangel av bedre ord).

Endret 24. februar 2017 av Slettet-Pqy3rC

[oppat]

Vel, hvis Google har redusert behovet for regnekraft med 100.000 så anta at det blir redusert med ihvertfall 1000 til ganske snart.

 

Det sitter nok andre med alternative teknikker som kan kombineres med de teknikkene som er brukt i dette angrepet.