Cryptography - suggested verification of Diffie-Hellman points

[randomstuff]

Suggested recuirement from Bart Preneel:

6.7.2. [ADDED] For Diffie-Hellman and Elliptic Curve Diffie-Hellman, verify that the point received is legitimate: e.g, for Diffie-Hellman the values 0, 1, and p-1 are not valid and for Elliptic Curve Diffie-Hellman (ECDH) the point should lie on the elliptic curve and should not be the point P or the point at infinity.

[randomstuff]

It is indeed important that the code verifies that the DH points are valid.

I think the wording should be instead:

6.7.2. [ADDED] Verify that the when the application receives a Diffie-Hellman point for Diffie-Hellman key agreement, it verified that this point is valid. For Finite Field Diffie-Hellman the values 0, 1, and p-1 are not valid. For Elliptic Curve Diffie-Hellman (ECDH), the point should lie on the elliptic curve and should not be the point P or the point at infinity.

Question: I'm wondering what "the point P" is? Are we talking about the generator of the subgroup? If so, this requirement should equally apply to FFDH?

About "the point P", should this requirement apply to FFDH as well (i.e. the point should not be the generator)?

[randomstuff]

See RFC 2631 for some validation of Finite Field Diffie-Hellman public keys.

[tghosth]

I defer to @danielcuthbert

[unprovable]

This is a very valid point, but totally dependent on whether they are writing their own curve code (which might raise other red flags if they aren't a large conglomerate or defence prime). But avoiding p-1, {p,0}, and 1 are very important things to do for ECDH - I'm not sure how often developers using libraries can make this kind of error though.

[randomstuff]

This is a very valid point, but totally dependent on whether they are writing their own curve code

Yes, the vulnerability could be in dependencies as well, though.

[tghosth]

@randomstuff do you think this is generally relevant enough to include, it sounds like a very specific case...

[randomstuff]

@tghost, I am not sure whether this is relevant enough to include in ASVS (or too low-level and not much a consideration in practice for people writing general application code).

I think this might apply for example if you use JWA/JKW/JWE/JWT (with ECDH-ES)? Would you have to take care of this case?

Also the current requirement is about "Diffie-Hellman and Elliptic Curve Diffie-Hellman". Would such a requirement apply as well to other EC uses such as signatures (ECDSA) for example?

I think we would have to review the impact on this kind of situation (JWE with ECDH-ES for example) from application code.

[tghosth]

Can you think of a case where the developer would be doing that themselves and not getting a library to do it...

[tghosth]

@randomstuff ping :)

[randomstuff]

Can you think of a case where the developer would be doing that themselves and not getting a library to do it...

@tghosth, I agree that application developer would be expected to use a high level library which takes care of this (… and I don't want to check that my TLS library actually does the right thing for me) however the same might be said of other crypto requirements such as:

• 6.5.3 Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key/data-element pair. The method of generation must be appropriate for the algorithm being used.
• 6.5.4 Verify that encrypted data is authenticated via signatures, as well as through authenticated cipher modes or HMAC for protection against unauthorized modification.
• 6.7.1 Verify that industry-proven cryptographic algorithms are used for key exchange (such as Diffie-Hellman) with a focus on ensuring that key exchange mechanisms use secure parameters. This should prevent attacks on the key establishment process which could lead to adversary-in-the-middle attacks or cryptographic breaks.
• 6.2.1 Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks.

I'm not sure where to draw the line between things which are too low-level (and we do not expect application code developers to have to touch without going through a library) vs. things which are not.

Some cases where the application developer might end up try to have to care about the validation of group elements (without claiming that these are good ideas):

• Implementing JOSE/COSE ECDSA (so not actually ECDH) signature verification without having a good library to do that (while still relying on reputed cryptographic library for implementing ECDSA signature validation). Would that be a problem? I don't know.
• Implementing your own end-so-end-secure chat (hum hum) using based on X3DH → Maybe not a great example, if you are implementing X3DH with the Curve25519 you don't need to validate the key.

[randomstuff]

This is a very valid point, but totally dependent on whether they are writing their own curve code (which might raise other red flags if they aren't a large conglomerate or defence prime).

Are we talking about "writing their own curve point computation and signature validation code" (which indeed is quite a read flag) or are we talking about "writing their own crypto code on top of existing ECDH/ECDSA library code" which might be more prevalent.

(For example, OpenSSL has EC_KEY_check_key() to check that a given EC key is valid. The verification appears to be done implicitly by some functions which create an EC_KEY* (such as EC_KEY_set_public_key_affine_coordinates) but if this function exists there must be some path which don't make the verification.)

[tghosth]

however the same might be said of other crypto requirements such as:

To me, each of those requirements are less detailed than specific/specific DH curves. My overall feeling from reading through this thread is that this topic is probably too detailed so I think I would be inclined to skip this recommendation or push it to an appendix discussion.

Do you have any strong objections @randomstuff ?

[randomstuff]

skip this recommendation

@tghosth, I'd say it's OK for me to skip this requirement.

push it to an appendix discussion

I am not sure how well it would fit in the appendix section however but why not.

[tghosth]

Ok so I will leave this issue open as a potential item to consider for the appendix but not for the v6 chapter itself, thanks!