Argon2d support

[rkeene]

For an application I'm writing I need to support Argon2d instead of only Argon2i. Is there any chance this can get added to monocypher -- I already use it for Ed25519+Blake2b as well regular Blake2b.

[LoupVaillant]

Yes, it could. I'm just not sure it should. I initially avoided it because it because Argon2d does not run in constant time, and thus could possibly leak secrets in some settings.

Adding Argon2d shouldn't cost too much code, though if I add it, I should probably add Argon2id as well, for the sake of completeness. (Or perhaps not. I disagree with Libsodium on that one, the default should be Argon2i.)

Now you're the first one to ever ask me for Argon2d. May I ask what your use case looks like?

[rkeene]

I'm only using Argon2d to be compatible with another piece of software which generates a 256-bit key using Argon2d:

https://github.com/nanocurrency/nano-node/blob/79e6756151df09635d4ce6cd06e5af1affc23c0a/nano/node/wallet.cpp#L740

[LoupVaillant]

Bad news: Monocypher cannot be compatible with Nano: the Argon2 version numbers don't match. Monocypher implements version 0x13, Nano uses version 0x10. I won't implement older versions, that's too much bloat for too little gain. They may update to version 0x13, but then will they still be using Argon2d? Will they stay single threaded (Monocypher can't go multi-thread for portability reasons).

You'll have to use the reference implementation, sorry.

That said, I'm not rejecting Argon2d just yet. Right now I have other things to do (like implementing proper key exchange protocols), but I'll leave this open in case someone else asks for it.

[ghost]

In my humble opinion, the appeal of Monocypher is that it is small, simple, and hard to misuse. Adding Argon2d would probably lead to adding Argon2id and supporting the whole set. Then Monocypher is not always side channel resistant, and additional documentation would have to point out when this is a problem.

I disagree with this approach. I think it's safer to provide the constant time version only. Not only does this reduce the code size and maintenance burden, but it also cuts down on misuse opportunities. There are obviously use cases where Argon2d is better, such as offline or local key derivation, but why give developers the ammo to shoot themselves in the foot?

To be honest, the Argon2 standard is disappointing in this regard. Instead of 1 algorithm for everyone to use we got 2, one of which is weaker but safer (sometimes), and the other is stronger but not as safe (but only sometimes). Then we got various versions of those. Then we got a third option which tries to be in between, but this came after a lot of code already uses the first two. I love Argon2 as an algorithm but as a standard it has turned into a bit of a mess.

The best approach as far as I'm concerned is to provide only Argon2i and watch it carefully.

Just my $.02

[rkeene]

Thanks !