dalek-cryptography / curve25519-dalek

A pure-Rust implementation of group operations on Ristretto and Curve25519
Other
853 stars 422 forks source link

Ed25519: should compare and hash use uncompressed points? #609

Closed simon-pau closed 7 months ago

simon-pau commented 7 months ago

Compare and hash currently use the as_bytes methods, which return the bytes of the compressed points. I am not sure whether this is correct, since some points can be encoded in different formats (at least on other curves). Is this not the case for ed25519? If this is the case, these methods should use the uncompressed bytes for these methods.

https://github.com/dalek-cryptography/curve25519-dalek/blob/main/ed25519-dalek/src/verifying.rs#L79 https://github.com/dalek-cryptography/curve25519-dalek/blob/main/ed25519-dalek/src/verifying.rs#L122

tarcieri commented 7 months ago

While uncompressed points are common with e.g. the NIST P-curves, Ed(wards)25519 points are universally compressed on the wire.

The main reason older curves used uncompressed points were as a workaround for point compression patents, which expired before/around the time Ed25519 was created.

Avoiding the uncompressed form on-the-wire means Ed25519 keys are always short and there's no need to deal with the incidental complexities of e.g. SEC1 tags which try to deal with handling both the compressed and uncompressed forms.

simon-pau commented 7 months ago

@tarcieri Thank you very much! If there is only one compressed format, the implementation is correct.