Esiste una tabella che confronta gli algoritmi di hashing in base alla velocità, relativamente (indipendente dalla macchina)

PBKDF2 e bcrypt sono configurati con un "conteggio di iterazione", il che significa che possono essere eseguiti nel modo più lento possibile. Pertanto, non può esserci una tabella che mostri quanto velocemente vadano. Quello che devi fare, invece, è decidere quanto tempo assegni alla funzione (ad esempio, vuoi che impieghi 0,05 secondi sul tuo server) e quindi impostare il numero di iterazioni di conseguenza. Questo dipende molto dalle capacità di calcolo del tuo server, quindi questa è una questione di misura sull'hardware di destinazione.

Per le altre funzioni, puoi trovare molti dati su questo sito per le misure di rendimento di molti funzioni hash su molte piattaforme (sebbene tutte queste piattaforme tendano ad essere server, sistemi desktop o, nel peggiore dei casi, smartphone), i sistemi embedded più piccoli non sono coperti. L'immagine di alto livello è:

• Le prestazioni dipendono molto dall'hardware.
• Le prestazioni dipendono molto dall'implementazione .
• Tutte le funzioni di hash attualmente definite sono troppo veloci per essere adeguate per l'hashing delle password da sole; hai bisogno di una sorta di rallentamento attraverso migliaia o milioni di iterazioni.

Mentre PBKDF2 aggiunge le iterazioni correttamente, può ancora essere reso molto più veloce nel contesto di un attacco parallelo, usando una GPU; quindi, potresti preferire usare una funzione che è ostile alla GPU e, in questo momento, questo significa bcrypt (scrypt è un buon candidato, quando diventa abbastanza vecchio per essere considerato attendibile). Vedi questa risposta per i dettagli.

Per ottenere una misurazione accurata, è necessario eseguire il benchmark utilizzando l'hardware previsto con il software desiderato. L'implementazione fa una grande differenza, oltre a un po 'di hardware può accelerare per determinati algoritmi.

Se intendi utilizzare OpenSSL, allora sei fortunato, perché hanno una suite di benchmarking integrata.

$ openssl speed md5 sha1 sha256
Doing md5 for 3s on 16 size blocks: 4595381 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 3732906 md5's in 3.00s
....
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              24508.70k    79635.33k   227390.21k   419190.78k   557154.30k
sha1             21918.90k    68573.48k   164350.12k   256347.14k   305924.78k
sha256           20979.09k    52742.04k   100939.52k   130634.07k   142630.91k

Tale tabella non ti aiuterà, scoprendo quale algoritmo hash è più adatto alle password hash. L'idea delle funzioni di derivazione chiave come Bcrypt e PBKDF2 è che il tempo necessario è configurabile e adattabile .

Ciò significa che, con un fattore di costo, decidi quante iterazioni vengono eseguite per ottenere una password. Regoli questo valore, quindi il tuo server non viene rallentato troppo, ma può contrastare gli attacchi brute force.

Dato che devi determinare da te il tempo concesso, non è così importante, quale funzione hash usi (per quanto riguarda il tempo). Ciò che può fare la differenza è, quanto è buona la funzione hash può essere implementata in una GPU. Ecco una tabella di strumento Hashcat 2012 . Un algoritmo che cerca di essere inefficace su GPU è Scrypt , Bcrypt è sicuramente anche una buona scelta.

Sì, sono necessari algoritmi lenti per l'hashing della password. Bcrypt e PBKDF2 sono entrambi grandi per questo scopo. Ecco un ottimo confronto tra i due

È difficile rispondere a una domanda indipendente dal computer, ma presumo che tu sia principalmente interessato all'hashing che utilizza un'applicazione desktop / server in Java. Alcune persone hanno eseguito alcuni degli algoritmi di hashing che hai citato su hardware dedicato GPU, FPGA o ASIC a una velocità vertiginosa. Il caso fortunato di Bcrypt e Scrypt è che è stato progettato per utilizzare la memoria lenta e resiste alle ottimizzazioni dello stile della GPU.

Anche PBKDF2 è buono e il NIST lo ha approvato per l'hashing della password. Anche l'implementazione .NET è conforme a FIPS. Quindi la velocità potrebbe non essere l'unica cosa che devi prendere in considerazione.

Anche se probabilmente non ne hai bisogno per questa domanda corrente, per riferimento futuro potresti essere interessato anche al sito crypto.SE per confrontare gli algoritmi, dal momento che dipende realmente da quale hardware genererà l'hash. Ad esempio, ecco un link che tratta scrypt .

Alcune di queste domande sono state poste prima, quindi è una buona idea cercare le domande, collegarle e fare una domanda sulla base di ciò che manca. Quindi, ancora una volta Security.SE è un gruppo di persone intelligenti e accoglienti, quindi penso che ti starai bene.

La seguente risposta è solo per la domanda specifica "c'è una tabella che ha benchmark relativi indipendenti dalla macchina di quegli algoritmi, ordinati per velocità?".

Tale tabella non può esistere poiché la velocità relativa dei diversi algoritmi è diversa a seconda della macchina utilizzata. Alcuni algoritmi (ad es. DES) sono stati progettati per essere veloci nell'hardware e lenti nel software. Altri algoritmi (ad esempio AES) sono stati progettati per accelerare nel software.

Esistono vari tipi di macchine che un utente malintenzionato probabilmente utilizzerà. I PC sono i più semplici da usare ma generalmente offrono le prestazioni più basse. I cracker seri hanno molte più probabilità di usare GPU. Molto probabilmente le organizzazioni finanziate, come i governi, useranno fattorie FPGA.

Anche se ci concentriamo sui cracker che usano GPU (i più probabili aggressori) ci sono differenze tra le GPU nelle prestazioni relative di diverse funzioni hash. Ciò è dovuto sia al tipo di GPU (CUDA o OpenCL) sia a causa delle diverse dimensioni della memoria (alcune funzioni hash richiedono una maggiore quantità di memoria rispetto ad altre). Ivan Golubev gestisce una grande tabella che confronta le prestazioni di quasi tutte le GPU sul mercato con alcune funzioni hash (ad esempio MD5, SHA1) anche se non bcrypt o scrypt.

Risposta breve:

• SHA-1 è fondamentalmente rotto, non usarlo mai.
• MD5 è debole, leggermente più strong con un sale.
• SHA-256 è OK per l'archiviazione delle password, comunque usa ancora un salatino.
• C'è un lotto di discussione che procede se bcrypt o PBKDF2 è "il migliore".
  • I fan di bcrypt sostengono che PBKDF2 può essere parallelizzato e quindi più veloce e più veloce.
  • I fan di PBKDF2 sostengono che l'uso di blowfish di bcrypt 'si indebolisce' perché blowfish non è stato studiato sufficientemente per la vulnerabilità e non è stato accettato 'ufficialmente' da X security org della settimana.
  • poi tutto si riduce a meschine denominazioni e "la tua mamma è così grassa ..." barzellette.

La linea di fondo è che usare PBKDF2 o bcrypt ti mette un miglio avanti a chiunque altro che non usa una funzione hash con un fattore di lavoro.