Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better wording to explain non-colliding of hedged Ed25519 and deterministic Ed25519. #14

Open
dannyniu opened this issue Oct 15, 2024 · 0 comments

Comments

@dannyniu
Copy link

Current wording (highlights' mine):

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant