[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:
Be happy to continue to try to clarify this, if you still have questions.
-mjm
From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> on behalf of Jakub Jelen <jjelen@redhat.com>
Sent: Tuesday, March 10, 2020 9:47 AM To: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]