Re: [openssl/openssl] Move EC & ECDH to providers (#10631)

From: notifications@github.com
Domain: IP info github.com
MX-server: IP info out-19.smtp.github.com
Size: 3747 Bytes
Create: 2020-02-15
Update: 2020-02-15
Score: 0
Safe: Yes

Outbound domains: github.com |

@romen commented on this pull request.


In include/openssl/core_names.h:

> @@ -185,6 +188,13 @@ extern "C" {
 #define OSSL_PKEY_PARAM_DSA_PUB_KEY  "pub"
 #define OSSL_PKEY_PARAM_DSA_PRIV_KEY "priv"
 
+/* Elliptic Curve Keys */
+#define OSSL_PKEY_PARAM_EC_PUB_KEY   "pub"

Well.. to me it seems the NIST data is not conforming to anything and not even defining rigorously how the affine coordinates are being represented...

The reference standard on how to represent a field element as an octet string is SECG SEC 1 v2.0 Paragrpah 2.3.5 and is well defined for coordinates on a prime field or a binary field.

For the NIST data it's not really defined rigorously how to interpret those hex strings, and in the CAVP FAQ about ECDSA (coudln't find a relevant section for ECC CDH) says:

12 ECDSA FAQ

ECDSA.1 For ECDSA PKV validation testing, how are the Qx and Qy values represented? What is the significance of their representation?

All values should be thought of as hexadecimal numbers. To determine whether a value
or a point is valid, convert it to a number; do not rely on the format (e.g., leading zeros,
number of hexadecimal symbols, etc.)

This doesn't really say how to convert the hexadecimal strings to "numbers", endianess, nor how it would map to a binary field coordinate.

Moreover sending separate x and y pairs creates a problem for representing the point at infinity.

My opinion is that any code that makes assumptions on how to read the NIST data and convert it to valid point coordinates should stay confined to the portion of code where those tests are being parsed/stored.

Tainting with ambiguity the interface between libcrypto <-> providers and providers <-> providers because of the ill defined format used by these tests does not seem the right choice.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Want to protect your real email from messages like this? Use TempM email and be more secure on the internet.