> 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 <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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
