For Curve25519, especially the X25519 key exchange, the RFC mention that a non-zero check can be done on the output, IMO this should be done in our usecase if we want to achieve our security goals. As per https://datatracker.ietf.org/doc/html/rfc7748#section-6.1:
Both MAY check, without leaking extra information about the value of K, whether K is the all-zero value and abort if so (see below)
This probably requires adding something to the spec, but it could be in the ECDH-1PU/ECDH-ES ones…
It would be something like “after key agreement, both parties should check the resulting key is non-zero”.
That being said there are arguments in the crypto community about whether or not this is necessary or not, some arguing it hurts security depending on your use-case / protocol…
From @AnomalRoil :
For Curve25519, especially the X25519 key exchange, the RFC mention that a non-zero check can be done on the output, IMO this should be done in our usecase if we want to achieve our security goals. As per https://datatracker.ietf.org/doc/html/rfc7748#section-6.1:
Both MAY check, without leaking extra information about the value of K, whether K is the all-zero value and abort if so (see below)
This probably requires adding something to the spec, but it could be in the ECDH-1PU/ECDH-ES ones… It would be something like “after key agreement, both parties should check the resulting key is non-zero”.
That being said there are arguments in the crypto community about whether or not this is necessary or not, some arguing it hurts security depending on your use-case / protocol…