You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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…
The text was updated successfully, but these errors were encountered:
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…
The text was updated successfully, but these errors were encountered: