Probably it was one of the main reasons why we didn't use pkcs11 for ATECC508A and wrote an engine instead
Regards, Alex. On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL < [email protected]> wrote: > Are you saying it won't work on OpenSSL_1_0_2-stable?! > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Douglas E Engert > *Sent: *Wednesday, January 20, 2016 14:07 > *To: *[email protected] > *Reply To: *[email protected] > *Subject: *Re: [openssl-dev] ECDH engine > > Patches are underdevelopment for OpenSC's libp11 and engine_pkcs11 to > support ECDH. There are waiting for OpenSSL-1.1 to be come stable > and some minor bug fixes. Testing is proceeding using OpenSSL-1.1-pre2 > today. OpenSSL-1.1 is needed because it exposes the functions needed > to use ECDH from an external engine i.e. the OPenSC engine_pkcs11. > > https://github.com/OpenSC/libp11/issues/52 > https://github.com/dengert/libp11/tree/prep-openssl-1.1 > https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1 > > In addition to a major rewrite of combining the ECDSA_METHOD and > ECDH_METHOD into an C_KEY_METHOD, OpenSSL-1.1 introduces a lot of changes, > mainly because it hides many of the structures that have been exposed in > the past. This causes a major rewrite of code to use functions to access > these structures. > > Although OpenSC could still use an older version of OpenSSL, there is also > underway changes for OpenSC to use OpenSSL-1.1: > https://github.com/OpenSC/OpenSC/pull/654 > https://github.com/dengert/OpenSC/tree/prep-openssl-1.1 > > > On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > I forgot to add that OpenSSL-1_0-2-stable with the current (Github > master) engine-pkcs11, libp11, and OpenSC successfully does ECDSA with keys > on the token (tested for ECC256 and ECC384). > > OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm > waiting for libp11 and engine_pkcs11 to add this capability. > > Ideally this is where your code would plug in, and complete the circle. > > As it currently is, a separate Atmel-specific ECC-specific engine is of a > limited usefulness. > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Blumenthal, Uri - 0553 - MITLL > *Sent: *Wednesday, January 20, 2016 12:46 > *To: *[email protected] > *Reply To: *[email protected] > *Subject: *Re: [openssl-dev] ECDH engine > > The ATECC508A is a chip. There are few USB devices built by Atmel on its > base. Or you can use the chip directly over I2C (that many people like to > do). You can follow the links that we posted on the ATECCX08 Engine > repository WiKi to learn about the chip. > > > I see, thanks. > > Well, our first indent was to use the pksc11 library. But it didn't go to > well for many reasons. I should go back for several months to collect these > reasons but I think the main reason was that ATECC508A hardware is based on > ECC-256 algorithms while pkcs11 is originally written for RSA - the > overhead was looking too high (many ATECC508 customers are using limited > hardware and want direct I2C connection to the chip). > > > There are a few hardware tokens (USB-pluggable), e.g. Yubikey, that > support ECC256 and (in case of Yubikey 4) ECC384. > > But let's talk about pkcs11. Can you point me to the set of documentation > for EC-DERIVE? It may be a good time now to add the ATECC508 support to > there. > > > Honestly, I’m more interested in adding ECDH support – assuming that it > would also serve ATECC508, rather than working on ATECC508B and hoping that > perhaps it would be usable for other ECC-capable tokens. > > Here’s the PKCS#11 spec > http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf, > which covers ECDH including ECDH1_DERIVE and ECDH1_COFACTOR_DERIVE. I > think older versions (like v2.20) have more content, but this is the > current one. > > Hope it helps. > > P.S. At this time I’m standing by my original opinion – that a better way > is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than > creating an engine specifically for one chip that add uncertainly of > non-interoperability with other chips/tokens. > > > On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL < > [email protected]> wrote: > > What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it > accessible via PKCS#11 at all? Is it accessible by/via OpenSC? > > I am trying to figure why such a generic and useful set of ECC operations > (Sign, Derive) is implementation-limited to one single <whatever>. > > A much better solution to me would be adding EC-DERIVE to engine_pkcs11, > and automatically get all the tokens covered. > > Since I'm probably missing something, could you please educate me? > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Alexander Gostrer > *Sent: *Wednesday, January 20, 2016 10:47 > *To: *Dr. Stephen Henson > *Reply To: * <[email protected]>[email protected] > *Cc: *[email protected] > *Subject: *Re: [openssl-dev] ECDH engine > > Hi Steve, > > And here is the ENGINE implementation for Atmel ATECC508A with few small > patches to OpenSSL_1_0_2-stable: > https://github.com/AtmelCSO/cryptoauth-openssl-engine > > Your comments are welcome. > > Regards, > Alex. > > On Sat, Dec 19, 2015 at 12:49 PM, Dr. Stephen Henson <[email protected]> > wrote: > >> On Fri, Dec 18, 2015, Alexander Gostrer wrote: >> >> > Hi Steve, >> > >> > John and I completed writing an ECDH engine based on the >> > OpenSSL_1_0_2-stable branch. We were planning to expand it to the master >> > but found some major changes made by you recently. What is the status of >> > this task? Is it stable enough to follow it? Are you planning another >> > changes? Is there a design document that we can use in our work? >> > >> >> The version in master shouldn't change much any more. Documentation will >> be >> available in the near future. The changes were meant to remove some of the >> weird "quirks" of ECC compared to other algortihms and to permit future >> expansion to a wider range of curves. >> >> In the meantime it shouldn't be too hard to follow how the new code works. >> Instead of separate ECDH/ECDSA methods with weird locking and ex_data and >> minimal ENGINE support everything is combined into a single EC_KEY_METHOD >> which can contain ECDSA, ECDH and key generation (something which was >> impossible with the old code) and be tied directly to an ENGINE. >> >> Most of the primary APIs such as ECDH_compute_key can be redirected >> directly >> through an engine supplied function in EC_KEY_METHOD. >> >> Having said that the code is very new and may have the odd bug that needs >> to >> be fixed. If you have any problems let me know and I'll look into them. >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > -- > > Douglas E. Engert <[email protected]> <[email protected]> > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > >
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
