26 Matching Annotations
 May 2020

nvlpubs.nist.gov nvlpubs.nist.gov

(Thus, for these curves, the cofactor is always h = 1.)
This means there is no need to check if the point is in the correct subgroup.

 Mar 2020

tools.ietf.org tools.ietf.org

Designers using these curves should be aware that for each public key, there are several publicly computable public keys that are equivalent to it, i.e., they produce the same shared secrets. Thus using a public key as an identifier and knowledge of a shared secret as proof of ownership (without including the public keys in the key derivation) might lead to subtle vulnerabilities.

Protocol designers using DiffieHellman over the curves defined in this document must not assume "contributory behaviour". Specially, contributory behaviour means that both parties' private keys contribute to the resulting shared key. Since curve25519 and curve448 have cofactors of 8 and 4 (respectively), an input point of small order will eliminate any contribution from the other party's private key. This situation can be detected by checking for the all zero output, which implementations MAY do, as specified in Section 6. However, a large number of existing implementations do not do this.

The check for the allzero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with small order, where the order divides the cofactor of the curve (see Section 7).

Both MAY check, without leaking extra information about the value of K, whether K is the allzero value and abort if so (see below).
Tags
Annotators
URL


nvlpubs.nist.gov nvlpubs.nist.gov

n
n is the order of the subgroup and n is prime

an ECC keyestablishment scheme requires the use of public keys that are affine ellipticcurve points chosen from a specific cyclic subgroup with prime order n
n is the order of the subgroup and n is prime

5.6.2.3.3ECC Full PublicKey Validation Routine

The recipient performs a successful full publickey validation of the received public key (see Sections 5.6.2.3.1for FFCdomain parameters andSection5.6.2.3.3for ECCdomain parameters).

Assurance of publickey validity –assurance that the public key of the other party (i.e., the claimed owner of the public key) has the (unique) correct representation for a nonidentity element of the correct cryptographic subgroup, as determined by the


prosecco.gforge.inria.fr prosecco.gforge.inria.fr

outside the subgroup


nvlpubs.nist.gov nvlpubs.nist.gov

5.6.2.3.2ECC Full PublicKey Validation Routine

The recipient performs a successful full publickey validation of the received public key (see Sections 5.6.2.3.1 and 5.6.2.3.2).

Assurance of publickey validity – assurance that the public key of the other party (i.e., the claimed owner of the public key) has the (unique) correct representation for a nonidentity element of the correct cryptographic subgroup, as determined by the domain parameters (see Sections 5.6.2.2.1 and 5.6.2.2.2). This assurance is required for both static and ephemeral public keys.


noiseprotocol.org noiseprotocol.org

Misusing public keys as secrets: It might be tempting to use a pattern with a premessage public key and assume that a successful handshake implies the other party's knowledge of the public key. Unfortunately, this is not the case, since setting public keys to invalid values might cause predictable DH output. For example, a Noise_NK_25519 initiator might send an invalid ephemeral public key to cause a known DH output of all zeros, despite not knowing the responder's static public key. If the parties want to authenticate with a shared secret, it should be used as a PSK.

Channel binding: Depending on the DH functions, it might be possible for a malicious party to engage in multiple sessions that derive the same shared secret key by setting public keys to invalid values that cause predictable DH output (as in the previous bullet). It might also be possible to set public keys to equivalent values that cause the same DH output for different inputs. This is why a higherlevel protocol should use the handshake hash (h) for a unique channel binding, instead of ck, as explained in Section 11.2.

The public_key either encodes some value which is a generator in a large primeorder group (which value may have multiple equivalent encodings), or is an invalid value. Implementations must handle invalid public keys either by returning some output which is purely a function of the public key and does not depend on the private key, or by signaling an error to the caller. The DH function may define more specific rules for handling invalid values.
Tags
Annotators
URL


hal.inria.fr hal.inria.fr

WireGuard excludes zero DiffieHellman shared secrets to avoid points of small order, while Noiserecommends not to perform this check
Tags
Annotators
URL


moderncrypto.org moderncrypto.org

This check strikes a delicate balance: It checks Y sufficiently to prevent forgery of a (Y, Y^x) pair without knowledge of X, but the rejected values for X are unlikely to be hit by an attacker flipping ciphertext bits in the leastsignificant portion of X. Stricter checking could easily *WEAKEN* security, e.g. the NISTmandated subgroup check would provide an oracle on whether a tampered X was square or nonsquare.

X25519 is very close to this ideal, with the exception that public keys have easilycomputed equivalent values. (Preventing equivalent values would require a different and more costly check. Instead, protocols should "bind" the exact public keys by MAC'ing them or hashing them into the session key.)

Curve25519 key generation uses scalar multiplication with a private key "clamped" so that it will always produce a valid public key, regardless of RNG behavior.

* Valid points have equivalent "invalid" representations, due to the cofactor, masking of the high bit, and (in a few cases) unreduced coordinates.

With all the talk of "validation", the reader of JP's essay is likely to think this check is equivalent to "full validation" (e.g. [SP80056A]), where only valid public keys are accepted (i.e. public keys which uniquely encode a generator of the correct subgroup).

(1) The proposed check has the goal of blacklisting a few input values. It's nowhere near full validation, does not match existing standards for ECDH input validation, and is not even applied to the input.


research.kudelskisecurity.com research.kudelskisecurity.com

If Alice generates allzero prekeys and identity key, and pushes them to the Signal’s servers, then all the peers who initiate a new session with Alice will encrypt their first message with the same key, derived from allzero shared secrets—essentially, the first message will be in the clear for an eavesdropper.

arguing that a zero check “adds complexity (consttime code, errorhandling, and implementation variance), and is not needed in good protocols.”
