Nice-to-have features

[jedisct1]

Some nice-to-have features. That may be out of scope for that document, but that would solve some real-world problems that all the widely used password hashing algorithms have.

1. Server relief. Allow the client to perform a part of the computation. In BKDF, hash is just the addition of the outputs of independent BalloonCore instantiations, so that can easily be implemented. Provided that pepper is empty, or can be computed as a shared secret.

2. Encryption. Section 9 refers to it, but maybe it would be an opportunity to define a standard way to do it. Introducing a dependency on AEADs is not required. Encryption can be made by leveraging the PRF.

3. The ability to upgrade parameters without having access to the passwords, similar to libhydrogen's pwhash_upgrade function. That would be a killer feature. In BKDF, the only way to achieve that would be to define a way to encode the composition of multiple BKDF calls. Probably out of scope for the document. But damn, that's something that would be really amazing to have in new password hashing functions.

[samuel-lucas6]

Thanks for these suggestions. Definitely worth thinking about. I never considered 1 with the same computation rather than calling the entire algorithm twice. For 2, the dilemma would probably be the conflict with the pepper parameter and maybe the output length. 3 would be nice but isn't something I've read into.