Hva ' er forskjellen mellom PBKDF og SHA og hvorfor bruke dem sammen?

Jeg har lest litt om hashing i det siste og ifølge AgileBits , de bruker « SHA512 i PBKDF2 » i sin nye hvelvfil.

Jeg har sett på Wikipedia etter begge navnene, og jeg vet at PBKDF2 er en nøkkelavledningsfunksjon og SHA er en kryptografisk hash-funksjon, men jeg kan ikke virkelig forstå forskjellen og hvorfor de begge brukes sammen med hverandre i hverandre.

Kan noen forklare dette for en person uten erfaring med kryptografi?

(Du kan anta at jeg bare vet om matematikk, om nødvendig).

Kommentarer

  • PBKDF2 er etter design mye tregere enn SHA, så det er bedre egnet for hashing av passord fordi det tar mye lengre tid å utføre en ordbok eller brute force-angrep.
  • @puzzlepalace så de gjør i utgangspunktet det samme og de bruker sammensetningen PBKDF2 (SHA (passord)) så det tar lengre tid før angripere?
  • I de fleste tilfeller bruker PBKDF2 en primitiv kalt HMAC som en psuedo-tilfeldig funksjon, som igjen bruker en kryptografisk hashfunksjon i den ‘ s internaler, i denne saken SHA512. Så sammensetningen ser virkelig ut som PBKDF2(HMAC_SHA512, password, ...).
  • PBKDF2 er bilen, HMAC er motoren, SHA512 er stempelet
  • Sistnevnte del av mitt svar på et tidligere spørsmål tar også opp dette.

Svar

SHA-512 er en kryptografisk sikker hash , PBKDF2 er det vi kaller en Password Based Key Derivation Function. Hvis den resulterende hemmeligheten ikke brukes som nøkkel, men som hash-verdi, kalles den også en passordhash . Passordhasher skiller seg fra sikre hash i den forstand at de inneholder et salt og en arbeidsfaktor / iterasjonstall.

Både kryptografiske hash og passordhash er enveisfunksjoner designet for å lage en kort, fast utdata fra en gitt innspill. Når det gjelder passord-hash, vil inngangen være passordet og saltet. Saltets størrelse og iterasjonstallet blir ofte sett på som konfigurasjonsparametere; begge påvirker selvsagt utdataene fra passordhash.

Passordhash er vanligvis bygget på toppen av Pseudo Random Functions eller PRFs. En vanlig form for PRF er en HMAC eller Hash-basert Message Authentication Code, som igjen bruker en hash internt. Når hash-baserte PRF-er som HMAC brukes, er typen / størrelsen på hasjen som brukes ofte konfigurerbar. Passord hashes trenger imidlertid ikke å bygges ved hjelp av hashes. Enhver annen PRF, for eksempel de som er basert på symmetriske koder, kan gjøre det. bcrypt er for eksempel bygget på toppen av Blowfish, en blokkering.

Passordhash trenger et salt slik at identiske passord ikke blir tilordnet samme hash. De forhindrer derfor også regnbuetabeller (som inneholder forhåndsberegnet passord / hash-par) fra å være nyttig. Videre inneholder de en arbeidsfaktor / iterasjonstall slik at en angriper trenger å utføre mer arbeid for å beregne hasjen til hvert mulige passord. Dette er nødvendig fordi de fleste passord ikke er tilfeldige nok. Uten arbeidsfaktoren angriper ville være i stand til å teste store mengder mulige passord ved hjelp av brute force eller et ordbokangrep.

Kommentarer

  • mye mer info her … passer ikke ‘ ikke i svarområdet.

Svar

For å omskrive mitt svar på et tidligere spørsmål , PBKDF2 er en generell algoritme på høyt nivå som kaller internt en pseudorandom-funksjon (PRF) for å behandle inngangen. PBKDF2-spesifikasjonen foreskriver ingen spesiell PRF, så implementatorer kan velge hvilken PRF de vil ha (så lenge den oppfyller definisjonen av en sikker PRF, og kan godta inngangen PBKDF2 gir den).

Når det skjer, er det klart vanligste valget av PRF for PBKDF2 HMAC , som er en annen høykonstruksjon som internt bruker en kryptografisk hashfunksjon . Igjen krever HMAC-spesifikasjonen ingen spesiell hashfunksjon, * så implementatorer kan velge hvilken som helst hash de vil ha. Sannsynligvis det vanligste valget i dag er en av SHA-2 familien av hashes, som inkluderer SHA-256 og SHA-512.

Så «SHA512 i PBKDF2» betyr nesten helt sikkert at de bruker PBKDF2 med HMAC som PRF, og med SHA-512 som hasj i HMAC. **

Det som kan være forvirrende er at blikk, denne PBKDF2-med-HMAC-med-SHA512 kan se ut som om den gjør noe veldig likt bare SHA-512: begge tar et vilkårlig passord som inngang og gjør det til en pseudorandom bitstreng som det opprinnelige passordet ikke være lett rekonstruert.Imidlertid er det faktisk flere forskjeller, de viktigste er at:

  • SHA-512 er rask. Veldig fort. PBKDF2 er bevisst treg å beregne, og dets treghet kan kontrolleres ved å justere parameteren for iterasjon.

  • Som en direkte konsekvens av hastigheten, SHA -512 alene er sårbar for brute force passord-gjetningsangrep ved hjelp av programvare som hashcat , som ganske enkelt genererer mange passord og hasj dem til de finner et som produserer en matchende hash . En enkelt moderne CPU kan enkelt hash millioner av passord per sekund, og GPUer er enda raskere.

I tillegg er det noen få andre mindre forskjeller med å merke seg:

  • PBKDF2 tar en «salt» -parameter, som kan brukes til å sikre at utgangene er unike selv om inngangspassordene ikke er . (Å bruke et salt motvirker også forhåndsberegningsbaserte angrep, siden angriperen ikke med fordel kan begynne å hashe gjettet passord før de vet saltet.) SHA-512 har ikke i seg selv begrepet salt, selv om en tilsvarende effekt kan oppnås f.eks. ved å forberede saltet til passordet.

  • SHA-512 gir alltid en 512-bit-utgang (derav navnet), selv om du alltid kan kutte den til en kortere lengde hvis du trenger ikke hele 512 bitene. PBKDF2 kan i prinsippet produsere utdata av hvilken som helst lengde, selv om i praksis bruker den til å generere mer enn en intern hash-utgang bits anbefales ikke .


*) Den opprinnelige HMAC-definisjonen og sikkerhetsbevisene antar effektivt at hashfunksjonen som brukes er av en bestemt type kjent som en Merkle – Damgård hash-funksjon . Når det skjer har alle de mest populære kryptografiske hashfunksjonene de siste tiårene, inkludert SHA-2-familien, vært av denne typen, så denne begrensningen har ikke vært noe stort problem i praksis. Dette kan endres gradvis med standardiseringen av SHA-3 (aka Keccak), som er ikke en Merkle – Damgård-hash, men kommer med sitt eget sikkerhetskrav for HMAC-SHA3 .

**) Dette er en bot og tradisjonelt valg, så langt det går. Det er ikke like motstandsdyktig mot GPU-baserte og andre parallelle angrep som mer moderne KDFer som scrypt eller Argon2 ville være, men det er fortsatt mye bedre enn vanlig gammel ikke-iterert hashing. Når det er sagt, for å evaluere sikkerheten riktig, trenger vi også å vite iterasjonstallet som brukes for PBKDF2. Dessverre har mange PBKDF2-implementeringer en tendens til å bruke det gamle «anbefalte minimumet» på 1000 iterasjoner, noe som er lite mer enn en fartsdump nå for tiden. Personlig, på en moderne CPU, Jeg foretrekker noe nærmere 1.000.000 eller 1.000.000.000 gjentakelser .

Kommentarer

  • Spørsmål: Brukes PBKDF2 bare for å redusere antall gjetninger (hvis bruteforce)? Eller er det noen andre detaljer å huske på?
  • @NaveenNiraula : I tillegg til å bremse brute force guessing, har PBKDF2 det sekundære formålet å konvertere passord med vilkårlig lengde og format til jevnt pseudorandom bitstrenger. Men bare hashing kan oppnå det også. Saltparameteren tillater å utlede flere forskjellige nøkler fra det samme passord, og forhindrer noen angrep med forhåndsberegnede ordbøker som » regnbuetabeller «. Men igjen, hvis du ikke ‘ trenger ikke brute force gjetningsbeskyttelse av PBKDF2, du kan bare bruke vanlig HMAC til det, eller til og med bare sammenkoble saltet med passordet før du hasher det.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *