On Wed, Jan 20, 2016 at 9:46 AM, Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote:
> 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. > Direct link: https://github.com/AtmelCSO/cryptoauth-openssl-engine/wiki > > 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. > Thanks > > 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. > Check our patches here: https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches. It is non-official openssl patches and probably will never go into but they are enabling ECDH enginee in stable-1.0.2. Limited use of course. > > 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. > I see your point. We'll look into it Thank you, Alex. > > > On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> 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: *openssl-dev@openssl.org > *Cc: *openssl-dev@openssl.org > *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 <st...@openssl.org> > 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 > >
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
