X25519 using fiat-crypto Curve25519 field arithmetic

[brycx]

TODO:

• Decide which exact tests, from Wycheproof, should be expected to fail. Should align with the RFC.
• Zeroizing Drop impl for FieldElement? -> FieldElement does not hold any secret bytes directly from Scalar so it seems fine to leave as-is.
• If Neg for FieldElement is not used because it is really only used through the fiat-crypto provided, then remove it.
• Documentation for all functions that do not have it yet
• Should FieldElement::as_bytes() mask the MSB as is done in from_bytes()? -> No, the masking is only needed when decoding an arbitrary byte-array into a FieldElement. as_bytes() encoding is handeled by fiat-crypto.
• Investigate if a cleaner approach is applicable for invert() for FieldElement -> Nothing convincing has come up so far. We leave this be for now, and can potentially re-investigate later on if it becomes an issue to review.
• Decide on whether to implement MulAssign for FieldElement or not (what about other *Assign ops?) -> Same argument as with finding a cleaner approach for invert().
• Scalar should not be exposed in the public API, but instead a mid-level type that is wrapped by a SecretKey-like type
• Missing error-handling
• General and differential fuzzing targets
• Create a new issue for the high-level interface for X25519
• SharedSecret newtype (can't use existing macro since a SharedSecret should not have a generate() function (maybe take same approach as with construct_public))

[vlmutolo]

Looking through the code (in a cursory way), I'm glad that you went with auto-generated implementations of the low-level math. There's actually plenty of complexity left to take on by hand even using the generated, proven code.

[brycx]

There's actually plenty of complexity left to take on by hand even using the generated, proven code.

Indeed. The code on top of fiat's already requires plenty to review and test.

[brycx]

The following flags are present in Wycheproof test vectors, which need to be taken into account:

• ZeroSharedSecret: We will reject these, as we perform a check for the result of the scalar multiplication and return Err if it is all-zero. The RFC does not require this ("MAY", see sec. 6.1).

• LowOrderPublic: We will reject these. Low order point public keys will produce an all-zero result. Since we test for this, and return an Err in that case, this flag indicates a failed test. All Wycheproof test cases with this flag also have the "ZeroSharedSecret" flag.

• SmallPublicKey: All test cases with this flag also have the "LowOrderPublic" and "ZeroSharedSecret" flags set which matches expectations based on RFC. These will be rejected.

• Twist: This flag should be accepted based on that the RFC does not recommend rejecting these (see sec. 7.):

"These
implementations could reject points on the twist and could reject
non-minimal field elements. While not recommended, such
implementations will interoperate with the Montgomery ladder
specified here but may be trivially distinguishable from it."

• NonCanonicalPublic: These will be accepted as it's a requirement in the RFC (see sec. 5):

"Implementations MUST accept non-canonical values and process them as
if they had been reduced modulo the field prime. The non-canonical
values are 2^255 - 19 through 2^255 - 1 for X25519 and 2^448 - 2^224 - 1 through 2^448 - 1 for X448."