Perché BCrypt.net GenerateSalt (31) tornare subito?

Question

mi sono imbattuto in BCrypt.net dopo aver letto posta Jeff Atwood sulle password memorizzazione che mi ha portato alla raccomandazione di Thomas Ptacek a uso bcrypt per memorizzare le password. Che alla fine mi ha portato a questo C # implementazione di bcrypt

Nei commenti sull'ultimo link qui sopra qualcuno ha chiesto: "Perché GenerateSalt (30) prendere per sempre, ma GenerateSalt (31) sembra prendere tempo a tutti?"

Mi sono imbattuto BCrypt.HashPassword (password, BCrypt.GenerateSalt (31)), e ottenuto il mio risultato a 0 millisecondi.

Ho corso BCrypt.HashPassword ( "password", BCrypt.GenerateSalt (30)) per più di 5 minuti ora e ancora non ho un risultato.

Mi rendo conto che non avrete probabilmente bisogno di un sale di 30 caratteri generata in modo casuale per creare i nostri hash delle password (o la crittografia irreversibili nel caso di bcrypt ) per anni. Modifica Ho dovuto leggere il codice un po ', logRounds non ha nulla a che fare con la lunghezza del sale. Grazie Aaronaught.

Così, perché GenerateSalt (31) restituiscono un valore quasi istantaneamente (quando dovrebbe prendere circa il doppio del tempo come GenerateSalt (30)?

Aggiorna

Ecco la correzione:

private byte[] CryptRaw(byte[] password, byte[] salt, int logRounds) {
    // ... snip ...
    uint rounds = 1U << logRounds;
    // ... snip
}

Answer 1

Ho il sospetto che il bug è qui:

private byte[] CryptRaw(byte[] password, byte[] salt, int logRounds) {
    // ... snip ...
    int rounds = 1 << logRounds;
    // ... snip
}

Quando si specifica 31 per il logRounds, si calcola che, come 2 ^ 32, che non può andare bene in un int e overflow, così l'hash è in realtà fatto in ... ehm, zero passaggi. L'autore dovrebbe avere invece uint utilizzato. Facile da fissare!

---

Anche voluto commentare questo:

  

Mi rendo conto che non faremo probabilmente bisogno di un generati in modo casuale 30 caratteri sale per creare la nostra password hash ...

Si noti che il parametro logRounds non si riferisce al numero di caratteri / byte nel sale, che è sempre 16. Essa si riferisce alla base logaritmica del numero di passaggi che l'hash prenderà calcolare; in altre parole si tratta di un modo per fare bcrypt scala con la Legge di Moore, rendendo la funzione di diversi ordini di grandezza più costoso per calcolare se i computer mai ottenere abbastanza veloce per rompere hash esistenti.

Answer 2

Se hashing con GenerateSalt(31) ritorna quasi immediatamente, questo è un bug. Si dovrebbe segnalare che a monte (ho, per jBCrypt). : -)

Per impostazione predefinita, il log-round è 10. Questo significa che (se non ricordo male), 1024 giri viene utilizzato. Ogni volta che si incrementerà il log-round, il numero di giri è raddoppiato.

A 30 log-round, si sta facendo 1073741824 turni. Questo richiede giustamente un lungo periodo di tempo. Al 31 log-round, round 2147483648 dovrebbe essere stato fatto, ma ho il sospetto che la particolare implementazione che si sta utilizzando, invece overflow. : - (