Come sottolinea @Rook, la maggior parte del vantaggio di hardware specializzato come GPU è attraverso la parallelizzazione. Un singolo core GPU, di per sé, è piuttosto debole; è sincronizzato a una frequenza inferiore a quella della CPU principale e calcolerà solo una operazione per ciclo di clock (al massimo e con latenza elevata). Tuttavia, una GPU include centinaia di core che ballano simultaneamente.
Ora, succede che le normali funzioni di hashing della password siano intrinsecamente sequenziali. Vedi ad esempio PBKDF2 : ogni chunk di output viene calcolato come risultato finale di una sequenza di U i valori, dove U i + 1 si ottiene elaborando U i con un PRF (normalmente HMAC). Questo non può essere reso parallelo. Se vuoi calcolare una singola istanza PBKDF2 su una GPU, allora userà solo un core su quella GPU, e questo sarà molto lento. Infatti, un tipico core GPU può avviare un'istruzione per cicli di clock, ma il risultato sarà disponibile solo dieci o venti cicli dopo, quindi la GPU viene utilizzata a pieno regime solo se ha migliaia di attività da eseguire in parallelo.
I malintenzionati traggono vantaggio dalla GPU perché, per definizione, l'utente malintenzionato ha molte potenziali password da provare. Così può usare il calcolo parallelo alla sua piena potenza; forzatura bruta delle password è un problema imbarazzante parallelo . Infatti, dal momento che ogni core GPU Il defender , d'altra parte, non ha molto hashing da fare: uno solo per cliente in entrata alla volta. Potremmo immaginare un server molto impegnato con, in qualsiasi momento, centinaia di client che tentano di aprire una sessione e che potrebbero essere suscettibili di ottimizzazione con una GPU, ma questo non è molto realistico.
Quindi, non esiste un'implementazione pronta all'uso di un framework di autenticazione che scarichi il costo di PBKDF2 o bcrypt su una GPU perché non funzionerebbe. Nel contesto dell'autenticazione dei client in arrivo (la situazione del difensore), il miglior hardware da utilizzare è la CPU, non una GPU.
Ciò detto, questo è dovuto al fatto che PBKDF2 e bcrypt (e anche scrypt e molte altre funzioni dello stesso tipo) sono sequenziali. Si potrebbero progettare funzioni di hashing della password che possono essere fatte in parallelo. A titolo illustrativo, immagina una funzione di hashing della password lenta progettata in questo modo:
- La password è pw , salt è s .
- Per i = 1 a 10000 , definisce V i = PBKDF2 ( pw || , s ).
- Il valore hash finale è SHA-256 ( V 1 || V 2 || ... || V 10000 ).
Nel caso di quella funzione, la maggior parte dello sforzo computazionale sono le decine di migliaia di istanze PBKDF2, che possono essere ottimizzate con una GPU, anche se si ha una sola password per l'hash.
( Attenzione: la funzione sopra è presentata solo come illustrazione speculativa.) Non credere che sia sicura! Questo non ha subito alcun tipo di revisione da parte di molti crittografi addestrati per diversi anni. )
C'è una competizione in corso per definire nuovi primitivi di hashing delle password, nello stesso spirito degli sforzi di AES, SHA-3 o eSTREAM . Se hai qualche idea interessante sulla definizione di una funzione di hashing della password suscettibile di parallelismo, allora, in ogni caso, considera di inviare un candidato.