You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The leading 0x00 octet in Hedged EdDSA provides domain separation with RFC 8032 since the first octets of dom2 and dom4 are distinct from 0x00. In the case of Ed25519, for which dom2 is the empty string, note that Ed25519 in RFC 8032 would have to contain the prefix also in PH(M) to collide with any of the inputs to the hash computations in the hedged variants in this document.
The bold is a bit unclear in my opinion. Can we come up with a better wording that explain it. For example, my attempt:
In the case of Ed25519 for which dom2 is the empty string, an attacker must somehow find a private key that collide with Z, then make signer sign both hedged Ed25519 as well as RFC-8032-style deterministic Ed25519 with different message that results in the same nonce-generation-hash input string - a situation that's improbable assuming proper protection of the secret key, and also out side the scope of hedged EdDSA.
The text was updated successfully, but these errors were encountered:
Current wording (highlights' mine):
The bold is a bit unclear in my opinion. Can we come up with a better wording that explain it. For example, my attempt:
The text was updated successfully, but these errors were encountered: