Pourquoi BCrypt.net GenerateSalt (31) revenir tout de suite?

Question

Je suis tombé sur BCrypt.net après avoir lu le post Jeff Atwood sur le stockage des mots de passe qui m'a conduit à la recommandation de Thomas Ptacek utilisation bcrypt pour stocker les mots de passe. Ce qui m'a finalement conduit à cette implémentation C # de bcrypt

Dans les commentaires sur le dernier lien ci-dessus quelqu'un a demandé « Pourquoi GenerateSalt (30) prendre pour toujours, mais GenerateSalt (31) semble prendre un rien de temps? »

Je courus BCrypt.HashPassword (mot de passe, BCrypt.GenerateSalt (31)) et obtenu mon résultat dans 0 millisecondes.

Je cours BCrypt.HashPassword ( "mot de passe", BCrypt.GenerateSalt (30)) pour plus de 5 minutes maintenant et ne disposent pas encore d'un résultat.

Je sais que nous allons probablement pas besoin d'un sel aléatoire de 30 caractères pour créer nos hashs (ou chiffrement irréversible en cas de bcrypt) pendant des années. EDIT J'ai lu un peu le code, logRounds n'a rien à voir avec la longueur de sel. Merci Aaronaught.

Alors, pourquoi GenerateSalt (31) retourne une valeur presque instantanément (quand il devrait prendre environ deux fois plus longtemps que GenerateSalt (30)?

UPDATE

Voici le correctif:

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

Answer 1

Je soupçonne que le bug est ici:

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

Lorsque vous spécifiez 31 pour le logRounds, il calcule que 2 ^ 32, ce qui ne rentre pas dans un int et trop-pleins, de sorte que le hachage est réellement fait dans ... euh, zéro passe. L'auteur aurait dû utiliser uint à la place. Facile à corriger!

---

voulais aussi commenter ceci:

  

Je sais que nous allons probablement pas besoin d'un 30 caractères générés aléatoirement sel pour créer notre hashs ...

Notez que le paramètre logRounds ne se réfère pas au nombre de caractères / octets dans le sel, ce qui est toujours 16. Il fait référence à la base logarithmique du nombre de passes que le hachage prendra pour calculer; en d'autres termes, il est un moyen de faire bcrypt échelle avec la loi de Moore, ce qui rend la fonction de plusieurs ordres de grandeur plus coûteux à calculer si les ordinateurs deviennent jamais assez vite pour se fissurer hachages existantes.

Answer 2

Si hachant avec GenerateSalt(31) retourne presque instantanément, c'est un bug. Vous devez signaler qu'en amont (je, pour jBCrypt). : -)

Par défaut, le journal est-tours 10. Cela signifie que (si je me souviens bien), 1024 tours est utilisé. Chaque fois que vous incrémenter les log-tours, le nombre de tours est doublé.

A 30 log-tours, vous faites 1073741824 tours. Cela prend à juste titre depuis longtemps. A 31 log-tours, 2147483648 tours devraient être être fait, mais je soupçonne que la mise en œuvre particulière que vous utilisez déversoirs à la place. : - (