Closed aep closed 6 years ago
Hi,
These are different libraries. They don't implement the same algorithms.
libsodium is more conservative, size is not a concern, and constructions are implemented as a ratatouille of many different primitives.
libhydrogen uses more modern constructions, size is a concern, and everything is built using a minimum number of primitives. In particular, the same curve is used both for signature and for key exchange.
that doesnt explain why it has to be incompatible with ed25519.
EdDSA requires SHA-2, and arithmetic over Curve25519 in Edwards form.
We already have a different hash function used everywhere else, and arithmetic over Curve25519 in Montgomery form used for key exchange. So we leverage what we already have. The primitives are different, but we still compute Schnorr signatures, over the same field size.
And although a variant with a randomized nonce has been specified to mitigate this, standard EdDSA is very fragile against side channel attacks. This is especially a concern on embedded systems. Libhydrogen signatures uses the same mechanism as this variant to produce non-deterministic signatures that still resist a weak RNG.
thanks for the explanation. I'd still prefer compatibility over saving sha2. A library that's only compatible with itself is going to struggle finding adoption, which again means less audits.
there doesnt appear to be any api to load an existing private key for ed25519.
hydro_sign_keygen_deterministic behaves different than libsodiums crypto_sign_ed25519_seed_keypair so the both cant be compatible