RFC: ED25519 Validation #28
Conversation
| Based on [research done by Henry de Valence](https://hdevalence.ca/blog/2020-10-04-its-25519am) we know that: | ||
| 1. Not all known implementations follow the decoding rules defined in RFC 8032. This causes validation results to vary across implementations. | ||
| 2. Even if the above point is fixed, the validation rules described in the RFC are not strict. So validation results vary even across implementations that adhere to RFC 8032. | ||
| 3. Even if the above points are fixed, we should note that a user holding the secret key to a signed message, can amend the signature so it remains valid. |
There was a problem hiding this comment.
- is technically not a direct consequence or content of Valence's post
There was a problem hiding this comment.
He did mention it that r is random a few times and it was just a good place in the motivation to the point across
There was a problem hiding this comment.
I agree, this should definitely go into the Motivation section, but I believe we have an extra paragraph for this. Thats why I wouldn't put it directly under his research.
|
@GalRogozinski |
* Update 0000-ed25519-validation.md * Fix typos
|
@charlesthompson3 It would be great, if you could also give this RFC a quick read |
|
@rootmos |
Co-authored-by: charlesthompson3 <74603461+charlesthompson3@users.noreply.github.com>
|
|
||
| Thus, in order to allow batch signature verification and its faster performance in IOTA nodes, the cofactored version _must_ be used for validation, i.e. the group equation [8][S]B = [8]R + [8][k]A' for the single verification. | ||
| Ed25519 also supports batch signature verification, which allows verifying several signatures in a single step, much faster than verifying signatures one-by-one. Without going into detail, there are also two alternative verification equations for the batch verification: | ||
| [8][∑z<sub>i</sub>s<sub>i</sub>] B = [8]∑[z<sub>i</sub>]R<sub>i</sub> + [8]∑[z<sub>i</sub>h<sub>i</sub>]A<sub>i</sub> and its corresponding cofactorless version. However, only cofactored verifications, single and batch, are compatible with each other. All other combinations are inconsistent and can lead to false positives or false negatives (see [Chalkias et al. 2020](https://eprint.iacr.org/2020/1244), Section 3.2).<br> Thus, in order to allow batch signature verification and its faster performance in IOTA nodes, the cofactored version _must_ be used for validation, i.e. the group equation [8][S]B = [8]R + [8][k]A' for the single verification. |
There was a problem hiding this comment.
its corresponding cofactorless version
Cofactorless version doesn't work (works incorrectly with high probability) with mixed-order points which we have to support for compatibility and etc. So there's only one suitable version of batch equation.
Cofactorless single and batch equations are consistent only in case where points are of prime order which we can't have.
There was a problem hiding this comment.
I honestly like the current version better. We don't have mentioned "mixed-order" and all this stuff anywhere yet. And I guess I'd rather leave it that way to keep the RFC concise. How about the following compromise:
However, only cofactored verifications, single and batch, are compatible with each other. All other combinations are inconsistent and can lead to false positives or false negatives (see Chalkias et al. 2020, Section 3.2) for certain edge-cases introduced by an attacker.
|
merged due to TIP refactor. |
|
|
||
| Based on [research done by Henry de Valence](https://hdevalence.ca/blog/2020-10-04-its-25519am) we know that: | ||
| 1. Not all implementations follow the decoding rules defined in RFC 8032, but instead accept non-canonically encoded inputs. | ||
| 2. The Ed25519 RFC provides two alternative verification equations, whereas one is stronger than the other. Different implementations use different equations and therefore validation results vary even across implementations that follow the RFC 8032. |
|
|
||
| # Motivation | ||
|
|
||
| Based on [research done by Henry de Valence](https://hdevalence.ca/blog/2020-10-04-its-25519am) we know that: |
There was a problem hiding this comment.
Shall we rather refer to Chalkias et al. 2020? It's referred to later anyway.
|
|
||
| ## Decoding | ||
|
|
||
| The Curve25519 is defined over the finite field of order p=2<sup>255</sup>−19. A curve point (x,y) is encoded into its compressed 32-byte representation, namely by the 255-bit encoding of the field element y followed by a single sign bit that is 1 for negative x (see [RFC 8032, Section 3.1](https://datatracker.ietf.org/doc/html/rfc8032#section-3.1)) and 0 otherwise. This approach provides a unique encoding for each valid point. However, there are two classes of edge cases representing non-canonical encodings of valid points: |
There was a problem hiding this comment.
[RFC 8032, Section 3.1](https://datatracker.ietf.org/doc/html/rfc8032#section-3.1)
Link to tools.ietf.org rather than to datatracker.ietf.org - [RFC 8032, Section 3.1](https://tools.ietf.org/html/rfc8032#section-3.1)
| 1. [8][S]B = [8]R + [8][k]A' | ||
| 2. [S]B = R + [k]A' | ||
|
|
||
| Each honestly generated signature following RFC 8032 satisfies the second, cofactorless equation and thus, also the first equation. However, the opposite is not true: There are solutions only satisfying the first but not the latter. This ambiguity in RFC 8032 has led to the current situation in which different implementations rely on different verification equations. |
There was a problem hiding this comment.
I propose to extend this paragraph as follows:
Each honestly generated signature following RFC 8032 satisfies the second, cofactorless equation and thus, also the first equation. However, the opposite is not true. This is due to the fact that dishonestly generated nonce R and public key A' might have order other than L. Testing whether a point has order L is costly. The first, cofactored equation accepts more nonces and public keys including dishonestly generated ones but lets us skip costly order checks. This has impact that each secret key has not 1 but 8 corresponding public keys and hence addresses. We deem this does not introduce any vulnerabilities. There are solutions only satisfying the first equation but not the latter. This ambiguity in RFC 8032 has led to the current situation in which different implementations rely on different verification equations.
| Analogous to RFC 8032, the encoding of S _must_ represent an integer less than L. | ||
|
|
||
| It is not possible for an external party to mutate R and still pass verification. The owner of the secret key, however, can create many different signatures for the same content: While Ed25519 defines a deterministic method of calculating the integer scalar r from the private key and the message, it is impossible to tell during signature verification if the point R = [r]B was created properly or any other scalar has been used.<br> As a result, there is a practically countless amount of different valid signatures corresponding to a certain message and public key. | ||
|
|
There was a problem hiding this comment.
Add a paragraph to describe special case of zero secret key:
We allow users to have a zero-scalar secret key and consider 8 corresponding public keys valid. However, users should not use it as it's equivalent to publishing one's secret key. This also has impact that any valid signature produced with a zero-scalar secret key will authenticate any message thus making it "super"-malleable.
| "valid": true | ||
| }, | ||
| { | ||
| "address": "00f25275baf4e267a1ec213dfd8283e9c97bf8c3494752c1c14b4bd5e5f9bfa9d8", |
There was a problem hiding this comment.
Address looks weird, it should be "003e7cca5d2979e71caa7325ce147026402da2aec6f95586be89e24f84bfb7f8fc" as in the test below. Was that intended?
Rendered