X25519 - set of rejected public keys differs from both NaCl and libsodium about tink

[thaidn]

Quan made this change, so I'll let him decide here.

My two cents:

I think we want to be compatible with RFC 7748 because it's the standard that we believe all implementations should follow.

I'm not sure how this would break compatibility though because these keys should never appear in normal computations.

Also what's the benefit for providing a way to fingerprint Tink and other implementations?

[thaidn]

For future reference:

The masking is done at https://github.com/google/tink/blob/master/java/src/main/java/com/google/crypto/tink/subtle/Curve25519.java#L347.

It makes the public key malleable. If someone uses this to implement ECIES, but doesn't include the ephemeral public key in the KDF, the ciphertext is malleable.

[NeilMadden]

Do you have a reference I could read for ciphertext malleability?

In our intended application we will be including both public keys in the KDF as a general best-practice, but I wasn't aware that failure to do that might render the ciphertext malleable.

[thaidn]

Hi Neil,

ECIES ciphertext consists an ephemeral public key. With the masking, someone can flip the last bit of the last byte of the ephemeral public key to obtain another valid ciphertext.

[NeilMadden]

OK, that makes sense. In our usage the ephemeral public key is also associated data to the AEAD used to encrypt the payload, so I believe that should prevent that.

[thaidn]

Quan, should we do anything here?

[cryptosubtlety]

I think it's a benign difference between libraries, so I will close it without making any change.