[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] Revisiting Montgomery and Edwards curves
Hi, In preparation of the F2F, I’ve added some responses below. 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. [DJ] No, I don’t think it was intentionally left out. The last three versions of the proposal included CKF_EC_CURVENAME. I think we
just missed it during the editorial phase. 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 be 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. These OIDs are more inline with my other proposal where key+params+alg are
It is odd, the OID owners do have OIDs for the pre-hashed variants. But for some reason they did not include them in RFC8410. 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? [DJ] In the proposal, a small table was added to section 2.3.17 and 2.3.18, which defined the key types supported for CKM_ECDH1_DERIVE
and CKM_ECDH1_COFACTOR_DERIVE. The table listed both CKK_EC and CKK_EC_MONTGOMERY. The intent was that those tables would show that the existing ECDH mechanisms could be used with the Montgomery curves. Maybe we need more information than just the tables?
Or a new mechanism as you suggest? Those tables were not added to the working draft. 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? [DJ] Is single-part vs multi-part something the spec should be dictating? I know it does today. But for the most part, the question
of single-part vs multi-part really comes down to a specific implementations complexity and resource constraints. Would it make sense to introduce some mechanism flags to let vendors define if each mechanism supports single-part or multi-part (or both) calling
conventions? From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Daniel Minder All, Sorry I forgot number Regards, Daniel -------- Ursprüngliche Nachricht -------- Von: Daniel Minder <Daniel.Minder@utimaco.com>
Datum: 14.02.19 18:02 (GMT+01:00)
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. Regards, Daniel
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]