On Wed, Jan 20, 2016 at 11:34 AM, Blumenthal, Uri - 0553 - MITLL < u...@ll.mit.edu> wrote:
> Probably it was one of the main reasons why we didn't use pkcs11 for > ATECC508A and wrote an engine instead > > > I still argue with the approach (IMHO nobody needs yet another limited > engine > Limited? - yes. Useless? - Probably, not. We will see it very soon. > ), but constraining ECC additions to 1.1 does not make any sense to me. > 1.0.2 is going to be around for a quite a while. A lot of applications > won’t migrate to 1.1 quickly – a few years would be a good/reasonable/safe > bet. > > To restrict this work to 1.1 means pushing this basic capability off by > (realistically) several years. Most people can’t/won't deploy openssl-1.1 > as long as it interferes with the majority of the applications they or > their OS is using, is not good. I for one won’t be able to use 1.1 in > practice until it becomes the embraced standard and software such as > Macports port set is moved to support it. I’m 100% sure there are many more > of us in this bus, on different OS (e.g., it looks like Ubuntu is even > worse off than Macports). > > > On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> 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: *openssl-dev@openssl.org >> *Reply To: *openssl-dev@openssl.org >> *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: *openssl-dev@openssl.org >> *Reply To: *openssl-dev@openssl.org >> *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 < >> 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>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 >> >> >> -- >> >> Douglas E. Engert <deeng...@gmail.com> <deeng...@gmail.com> >> >> >> >> _______________________________________________ >> 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