RE: [pkcs11] Revisiting Montgomery and Edwards curves

Hi again,

Adding more to question 2 and mostly answering question 3:

To 2. We (PKCS#11) extended the Parameters CHOICE by the curveName to be able to specify the new curves. Thus, our intention was to use id-ecPublicKey in the algorithm field of the AlgorithmIdentifier as for other elliptic curves and define the exact curve via parameters. RFC 8410 directly uses the 4 OIDs in the algorithm field and “parameters MUST be absent” (from the RFC). This will lead to incompatibilities.

To 3. In the eddsa_notes_Additional_EC_Key_Types_draft4 the section “Elliptic curve Diffie-Hellman key derivation” was extended by short “constraints on key types” with a table. This didn’t make it to WD08.

However, in my opinion we need to change the explanatory text since ECDH for Montgomery curves does not work according to X9.63 but according to RFC 7748. And therefore, there is no cofactor key derivation. Thus, this extension must not be added to section “1.0.17 Elliptic curve Diffie-Hellman with cofactor key derivation” as in eddsa_notes_Additional_EC_Key_Types_draft4.

Regards,

Daniel

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Daniel Minder
Sent: Donnerstag, 14. Februar 2019 19:30
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Revisiting Montgomery and Edwards curves

All,

Sorry I forgot number

4. For the non-prehashed EdDSA variants the message needs to be processed twice by the function. Therefore, they are single-shot and cannot be used with update/final. Shall we mention this explicitly and agree on an error code?

Regards,

Daniel

-------- Ursprüngliche Nachricht --------

Von: Daniel Minder <Daniel.Minder@utimaco.com>

Datum: 14.02.19 18:02 (GMT+01:00)

An: pkcs11@lists.oasis-open.org

Betreff: [pkcs11] Revisiting Montgomery and Edwards curves

Hi,

when having a closer look at RFCs 7748, 8032 and 8410, some questions concerning Montgomery and Edwards curves came to my mind related to PKCS#11 3.0 Current Mechanisms Working Draft 08 Section 2.3.

1. Was it intentional not to include CKF_EC_CURVENAME in Table 34? Although we mention this flag later on in the text, it's neither defined in the header files nor used anywhere else.

2. RFC 8410 now defines four OIDs for Ed25519, Ed448, X25519 and X448. Note that this not only denotes the curve but also the algorithm. This was a conscious decision (see e.g. https://mailarchive.ietf.org/arch/msg/curdle/OL3Y4ohwleOukV8CMkE9kgrFPZg). Our WD08 refers to "a curve name as defined in RFC 8032" and gives as example "Edwards25519". (The same holds for Montgomery curves, but no example is given.) Thus, it does not make the distinction between the different algorithms. Instead, the CKM_EDDSA mechanism gets a parameter that specifies the algorithm.

2a. Shall we keep this approach?

2b. Shall we also allow to use the four OIDs defined in RFC 8410 to identify a curve? Then, the mechanism would be restricted to the "Pure" version and no mechanism parameter is allowed.

3. There is the Extended Triple Diffie-Hellman algorithm working on Montgomery curves, but I'm missing the "normal" ECDH mechanism working on curve25519/curve448 as described in RFC 7748 section 6. Or shall CKM_ECDH1_DERIVE with KDF_NULL and empty sharedData be used? Or better introduce a new mechanism?

Regards,

Daniel

pkcs11 message