Wat is ' is het verschil tussen PBKDF en SHA en waarom zouden we ze samen gebruiken?

Ik “lees de laatste tijd een beetje over hashing en volgens AgileBits , ze gebruiken “ SHA512 binnen PBKDF2 ” in hun nieuwe kluisbestand.

Ik heb in Wikipedia naar beide namen gekeken en ik weet dat PBKDF2 een sleutelafleidingsfunctie is en SHA een cryptografische hash-functie, maar ik kan het verschil niet echt begrijpen en waarom ze allebei samen met de ene in de andere worden gebruikt.

Kan iemand dit uitleggen voor een persoon zonder ervaring in cryptografie?

(Je kunt aannemen dat ik alleen van wiskunde af weet, indien nodig).

Opmerkingen

  • PBKDF2 is per definitie veel langzamer dan SHA, dus het is beter geschikt voor het hashen van wachtwoorden omdat het veel langer duurt om een woordenboek- of brute force-aanval uit te voeren.
  • @puzzlepalace dus ze doen in wezen hetzelfde en ze gebruiken de samenstelling PBKDF2 (SHA (wachtwoord)), dus het duurt langer voor aanvallers?
  • In de meeste gevallen gebruikt PBKDF2 een primitief genaamd HMAC als een psuedo-random-functie, die op zijn beurt een cryptografische hash-functie erin gebruikt ‘ s internals, in dit geval SHA512. Dus de compositie lijkt echt meer op PBKDF2(HMAC_SHA512, password, ...).
  • PBKDF2 is de auto, HMAC is de motor, SHA512 is de zuiger
  • De laatste een deel van mijn antwoord op een eerdere vraag behandelt dit ook.

Antwoord

SHA-512 is een cryptografisch veilige hash , PBKDF2 is wat we een op wachtwoorden gebaseerde sleutelafleidingsfunctie noemen. Als het resulterende geheim niet als sleutel maar als hash-waarde wordt gebruikt, wordt het ook een wachtwoord-hash genoemd. Wachtwoord-hashes verschillen van veilige hashes in de zin dat ze een salt en een werkfactor / iteratietelling bevatten.

Zowel cryptografische hashes als wachtwoord-hashes zijn eenrichtingsfuncties die zijn ontworpen om een korte uitvoer met een vaste grootte te creëren van een gegeven input. In het geval van de wachtwoord-hash zou de invoer het wachtwoord en salt zijn. De grootte van het zout en het aantal iteraties worden algemeen beschouwd als configuratieparameters; beide hebben natuurlijk invloed op de output van de wachtwoord-hash.

Wachtwoord-hashes worden over het algemeen bovenop Pseudo Random Functions of PRFs gebouwd. Een gebruikelijke vorm van PRF is een op HMAC of hash gebaseerde Message Authentication Code, die op zijn beurt intern een hash gebruikt. Wanneer op hash gebaseerde PRFs zoals HMAC worden gebruikt, is het type / de grootte van de hash die wordt gebruikt vaak configureerbaar. Wachtwoord-hashes hoeven echter niet te worden opgebouwd met hashes. Elke andere PRF, zoals die op basis van symmetrische cijfers, kan doen. bcrypt is bijvoorbeeld gebouwd bovenop Blowfish, een blokcijfer.

Wachtwoord-hashes hebben een salt nodig zodat identieke wachtwoorden niet aan dezelfde hash worden toegewezen. Ze voorkomen daarom ook regenboogtabellen (met vooraf berekend wachtwoord / hash-paren) niet nuttig zijn. Bovendien bevatten ze een werkfactor / iteratietelling, zodat een aanvaller meer werk moet doen om de hash van elk mogelijk wachtwoord te berekenen. Dit is nodig omdat de meeste wachtwoorden niet willekeurig genoeg zijn. Zonder de werkfactor is de aanvaller zou in staat zijn om grote hoeveelheden mogelijke wachtwoorden te testen met brute kracht of een woordenboekaanval.

Reacties

  • veel meer info hier … past niet ‘ in de antwoordruimte.

Antwoord

Om mijn antwoord op een eerdere vraag te parafraseren, PBKDF2 is een generiek algoritme op hoog niveau dat roept intern een pseudorandom-functie (PRF) aan om zijn invoer te verwerken. De PBKDF2-specificatie stelt geen specifieke PRF verplicht, dus het staat implementeerders vrij om elke PRF te kiezen die ze willen (zolang deze voldoet aan de definitie van een beveiligde PRF en de invoer die PBKDF2 eraan geeft, kan accepteren).

Toevallig is de meest gebruikelijke PRF-keuze voor PBKDF2 HMAC , wat een andere constructie op hoog niveau is die intern gebruikt een cryptografische hashfunctie . Nogmaals, de HMAC-specificatie stelt geen specifieke hash-functie *, dus het staat implementeerders vrij om elke gewenste hash te kiezen. Waarschijnlijk de meest gebruikelijke keuze van tegenwoordig is een hashes uit de SHA-2 -familie, waaronder SHA-256 en SHA-512.

Dus “SHA512 binnen PBKDF2” betekent vrijwel zeker dat ze “PBKDF2 gebruiken met HMAC als de PRF, en met SHA-512 als de hash in HMAC. **

Wat verwarrend kan zijn, is dat, op een gegeven moment blik, deze PBKDF2-met-HMAC-met-SHA512 kan eruit zien alsof hij iets doet dat erg lijkt op gewoon SHA-512: beide nemen een willekeurig wachtwoord als invoer en veranderen het in een pseudo-willekeurige bitreeks waarvan het originele wachtwoord niet kan gemakkelijk worden gereconstrueerd.Er zijn echter in feite een aantal verschillen, waarvan de belangrijkste zijn dat:

  • SHA-512 is snel. Erg snel. PBKDF2 is opzettelijk traag om te berekenen, en zijn traagheid kan worden gecontroleerd door de iteratietellerparameter aan te passen.

  • Als een direct gevolg van zijn snelheid kan SHA -512 alleen is kwetsbaar voor brute force-aanvallen om wachtwoorden te raden met behulp van software zoals hashcat , die simpelweg veel wachtwoorden genereren en deze hashen totdat ze er een vinden die een overeenkomende hash produceert . Een enkele moderne CPU kan gemakkelijk miljoenen wachtwoorden per seconde hashen, en GPUs zijn zelfs nog sneller.

Daarnaast zijn er een paar andere kleine verschillen met de opmerking:


*) De originele HMAC-definitie en beveiligingsbewijzen gaan er in feite vanuit dat de gebruikte hashfunctie van een bepaalde type bekend als een Merkle – Damgård hashfunctie . Toevallig waren alle populairste cryptografische hash-functies van de afgelopen decennia, inclusief de SHA-2-familie, van dit type, dus deze beperking is in de praktijk niet echt een probleem geweest. Dit kan geleidelijk veranderen met de standaardisatie van SHA-3 (ook bekend als Keccak), die geen een Merkle-Damgård-hash is, maar handig, wordt geleverd met zijn eigen beveiligingsclaim voor HMAC-SHA3 .

**) Dit is een boete en traditionele keuze, voor zover het gaat. Het is niet zo resistent tegen GPU-gebaseerde en andere parallelle aanvallen als modernere KDFs zoals scrypt of Argon2 zou zijn, maar het is nog steeds een stuk beter dan gewone, niet-itereerde hashing. Dat gezegd hebbende, om de beveiliging goed te kunnen evalueren, zouden we ook het aantal iteraties moeten weten dat voor PBKDF2 wordt gebruikt. Helaas hebben veel PBKDF2-implementaties de neiging om het oude “aanbevolen minimum” van 1000 iteraties te gebruiken, wat tegenwoordig weinig meer is dan een verkeersdrempel. Persoonlijk, op een moderne CPU, zou ik “liever iets hebben dat dichter bij 1.000.000 of 1.000.000.000 iteraties ligt .

Opmerkingen

  • Vraag: wordt PBKDF2 alleen gebruikt om het aantal gissingen te vertragen (indien bruteforce)? Of zijn er andere details om in gedachten te houden?
  • @NaveenNiraula : Naast het vertragen van het raden van brute kracht, heeft PBKDF2 ook het secundaire doel om wachtwoorden van willekeurige lengte en indeling om te zetten in uniform pseudo-willekeurige bitstrings. Maar gewoon hashing zou dat ook kunnen bereiken. De parameter salt maakt het ook mogelijk om meerdere verschillende sleutels uit dezelfde wachtwoord en voorkomt aanvallen met behulp van vooraf berekende woordenboeken zoals ” regenboogtabellen “. Maar nogmaals, als u ‘ t heeft de brute force-gisbescherming van PBKDF2 nodig, je zou daarvoor gewoon HMAC kunnen gebruiken, of zelfs gewoon het zout aaneenschakelen met het wachtwoord voordat je hashing het.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *