Re: [pkcs11] Edwards ECC keys in PKCS #11 3.0 again

Jakub:  Not sure this is going to help as I don't fully understand the questions in your message, but in the hope that it will, I'll proceed.

First of all, 8032 is a specification for signatures using (twisted) Edwards curves Ed25519/Ed448, while 8410 covers those curves as well as the (birationally equivalent/2-isogenous) curves in Montgomery form called X448/X25519 (aka, Curve25519/Curve448
 in SP800-186). The latter are only used for the key agreement schemes X25519 and X448 (RFC 7748). I'd recommend looking at NIST SP800-186 to help sort out the relationships between these curves. (https://mailarchive.ietf.org/arch/msg/cfrg/-9LEdnzVrE5RORux3Oo_oDDRksU/ is
 also helpful)

Once that's understood, you should also note the difference between the "key generation" ftns for EdDSA and ECDH. (Modulo some bit tweaking...) EdDSA takes a random private key octet string, hashes it, multiplies the base point by that hash value interpreted
 as an integer, then combines the y coordinate with a compressed x coordinate to obtain the "public key" octet string (FIPS 186-5 section 7.2). Fairly conventional.

OTOH, for X25519/X448 (i.e., ECDH with Curve25519/Curve448), all computations are based solely on x coordinates and one never really has to generate a public point; which results in a certain ambiguity about which point would have been the corresponding "public
 key" in a classical ECC scheme. In fact, what gets published here as a "public key" is the value of the ftn X25519(x,9) (resp., X448(x,5)) evaluated at the private key x and encoded as an octet string. (See RFC 7748 sections 5&6.)

This might be the meaning of "keys defined by RFC 8032 and RFC 8410 are incompatible" that you seek... or it might not.

The discussion here will either help or confuse you further:

https://crypto.stackexchange.com/questions/68121/curve25519-over-ed25519-for-key-exchange-why

Be happy to continue to try to clarify this, if you still have questions.

-mjm

From:  <> on behalf of Jakub Jelen <>

Sent: Tuesday, March 10, 2020 9:47 AM

To:  <>

Subject: [pkcs11] Edwards ECC keys in PKCS #11 3.0 again

 

Hello all,

I made my way through the implementation of the Edwards ECC keys

support in few projects and while trying inter-operability tests among

different modules and tooles, it turned out that there are still few

bits that are not clear to me (nor for other people trying to review my

changes and the specs). Assuming this will be a common problem for

others, I believe this can be a base for 3.1/errata or some

clarification statement

1) The value of CKA_EC_POINT of CKK_EC_EDWARDS keys is described as

follows:

> DER-encoding of the b-bit public key value in little endian order as

defined in RFC 8032

But this really misses implementation details. The reference to RFC

8032 can mean that the value is encoded as "octet strings" (which would

match how the ECDSA keys are encoded). To this question, I was brought

by the following discussion in the gnutls [1], which initially

implemented the EC_POINT as raw bit string.

2) The value of CKA_EC_PARAMS can be either OID or the curve name. The

example templates show the usage of curve name version only. The

initial implementation of SoftHSM supported only OIDs, but I extended

it to support curve names and use them by default [2]. The PKCS #11 3.0

says:

> Edwards EC public keys only support the use of the curveName

selection to specify a curve name as defined in [RFC 8032] and the use

of the oID selection to specify a curve through an EdDSA algorithm as

defined in [RFC 8410].

But from my reading of both RFCs and all around and along the lines, I

was able to figure out that the RFC 8042 specifies the algorithm itself

and RFC 8410 compatible signature algorithms for PKI. But this sounds

like in contradiction with the following sentence:

> Note that keys defined by RFC 8032 and RFC 8410 are incompatible.

Did the author mean that not all of the named curves have appropriate

OIDs? Or that the applications should not attempt to make them

compatible even if they are the same curve (to my understanding)? Or

something else?

Is there one definition that should be preferred for the tools creating

keys and pkcs11 modules presenting existing keys?

[1] https://gitlab.com/gnutls/gnutls/-/merge_requests/1200

[2] https://github.com/opendnssec/SoftHSMv2/pull/526

[3] https://www.openssl.org/docs/man1.1.1/man7/Ed25519.html

Regards,

-- 

Jakub Jelen

Senior Software Engineer

Security Technologies

Red Hat, Inc.

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that 

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php