Por que o BCRYPT.NET GeraSalt (31) retorna imediatamente?

Question

Eu tropecei em Bcrypt.net depois de ler O post de Jeff Atwood sobre armazenar senhas o que me levou à recomendação de Thomas Ptacek para Use BCrypt Para armazenar senhas. Que finalmente me levou a Esta implementação C# BCRYPT

Nos comentários sobre o último link acima, alguém perguntou: "Por que o Generatesalt (30) leva para sempre, mas Generatesalt (31) parece não levar tempo?"

Eu executei bcrypt.hashpassword (senha, bcrypt.generatesalt (31)) e obtive meu resultado em 0 milissegundos.

Eu tenho executado bcrypt.hashpassword ("senha", bcrypt.generatesalt (30)) há mais de 5 minutos agora e ainda não tenho resultado.

Sei que provavelmente não precisaremos de um sal de 30 caracteres gerado aleatoriamente para criar nossos hashes de senha (ou criptografia irreversível no caso de BCRYPT) por anos. EDITAR Eu deveria ter lido um pouco o código, o LogRounds não tem nada a ver com o comprimento do sal. Obrigado AaronAught.

Então, por que o Generatesalt (31) retorna um valor quase instantaneamente (quando deve levar cerca de duas vezes mais que o generatesalt (30)?

ATUALIZAR

Aqui está a correção:

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

Answer 1

Eu suspeito que o bug esteja aqui:

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

Quando você especifica 31 para o logRounds, ele calcula que 2^32, que não podem caber em um int e transbordam, então o hash é realmente feito ... er, zero passa. O autor deveria ter usado uint em vez de. Fácil de consertar!

---

Também queria comentar sobre isso:

Sei que provavelmente não precisaremos de um sal de 30 caracteres gerados aleatoriamente para criar nossos hashes de senha ...

Observe que o logRounds O parâmetro não se refere ao número de caracteres/bytes no sal, que é sempre 16. Refere -se à base logarítmica do número de passes que o hash levará para calcular; Em outras palavras, é uma maneira de tornar a escala BCRYPT com a lei de Moore, tornando a função várias ordens de magnitude mais caras para calcular se os computadores forem rápidos o suficiente para quebrar os hashes existentes.

Answer 2

Se hash com GenerateSalt(31) Retorna quase instantaneamente, isso é um bug. Você deve relatar isso upstream (eu tenho, para JBCrypt). :-)

Por padrão, os logs-rounds são 10. Isso significa que (se bem me lembro), 1024 rodadas são usadas. Cada vez que você incrementa os logs, o número de rodadas é dobrado.

Com 30 loglds, você está fazendo 1073741824 rodadas. Isso leva muito tempo. Em 31 logs-rounds, 2147483648 rodadas devem estar sendo feitas, mas suspeito que a implementação específica que você esteja usando transborda. :-(