"Stephen R. van den Berg" <[email protected]> writes: > +int > +blowfish_bcrypt_hash(size_t length, > + char *dst, > + const char *key, > + const char *scheme, > + int log2rounds, > + const uint8_t *salt); > +int > +blowfish_bcrypt_verify(const char *key, > + const char *hashed);
I think it's nice with separate hash/verify functions. Code looks reasonable, but I still have a few questions on the interface: If I get it right, the parameters log2rounds and salt can either be provided as explicit arguments, or derived from the scheme string. In some way, it would be clenaer with one function taking all parameters as explicit arguments (without any scheme string to parse at all), and a different one taking it all from the scheme string. Do we need anything in the middle, like parsing log2rounds from the scheme string, but the salt as a separate binary string? It's unusual in the Nettle API to use NUL-terminated strings, we usually pass length and data. E.g., the pbkdf2 functions take the input password as size_t key_length, const uint8_t *key, even though it's usually an ascii string. It's not clear what's best here. Will the algorithm break down if we let it process a key input with NUL character in the middle? The length input (first argument) seems redundant, since its only use is to check that it's >= BLOWFISH_BCRYPT_HASH_SIZE. When the sie really is fixed, it's better to document that and drop that argument. If you would like to make some easy progress, you could split out the patch to create blowfish-internal.h and declare _nettle_blowfish_encround in that file. That has no api implications and would reduce the size of the main patch. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
