[openssl-dev] ECDH engine

Wed Jan 20 20:27:07 UTC 2016

On Wed, Jan 20, 2016 at 12:19 PM, Blumenthal, Uri - 0553 - MITLL <
uri at ll.mit.edu> wrote:

> Very possible that I'm missing the point here.
>
> Still, since openssl-1_0_2 does ECDH, and it exposes ‎ECDSA to external
> engine(s), how difficult would it be to add ECDH exposure? I suspect - a
> good deal easier than getting 1.1 replace 1.0.x as the de-facto deployment
> standard.
>
> Plus, by this time there already are (and reasonably common) tokens that
> support ECDH, other packages that do ECDH, and people (like myself :-)
> willing to test it and offer minor enhancements.
>
> Another point I seem to be missing - if what's necessary to implement ECDH
> in an external engine is missing from 1_0_2 - how could ‎Alexander write a
> (presumably) working ECDH engine for 1_0_2? If he could do it,  why can't
> engine_pkcs11 be extended to do the same?
>

As I said, we were needed to patch 1_0_2 to make it working (see patches
here:
https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches).
Changes are pretty minor. We will be more than happy if the openssl
community will agree to apply these patches to the 1_0_2 branch. But I was
said that it is unlikely to happen because it is more feature than bug.
Also we tested them for TLS-1.2 only.

>
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
> *From: *Douglas E Engert
> *Sent: *Wednesday, January 20, 2016 14:59
> *To: *openssl-dev at openssl.org‎
> *Reply To: *openssl-dev at openssl.org
> *Subject: *Re: [openssl-dev] ECDH engine
> ‎
> You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to
> external engines.  It took years to even get ECDSA exposed.
> OpenSSL approach to support this is OpenSSL-1.1  that does a lot of other
> things. But that was there approach. Its their package.
> From working package to distribution always takes several years...
>
>
>
> ‎
> On 1/20/2016 1:34 PM, Blumenthal, Uri - 0553 - MITLL 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), 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 <
> uri at 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 at openssl.org>openssl-dev at openssl.org
>> *Reply To: * <openssl-dev at openssl.org>openssl-dev at 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 at openssl.org>openssl-dev at openssl.org
>> *Reply To: * <openssl-dev at openssl.org>openssl-dev at 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>
>> 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 <
>> uri at 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 at openssl.org>openssl-dev at openssl.org
>> *Cc: * <openssl-dev at openssl.org>openssl-dev at 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>
>> 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 <
>> <steve at openssl.org>steve at 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>
>>> http://www.openssl.org
>>>
>>
>>
>> _______________________________________________
>> openssl-dev mailing list
>> To unsubscribe: <https://mta.openssl.org/mailman/listinfo/openssl-dev>
>> 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  <DEEngert at gmail.com> <DEEngert at 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
>
>
> --
>
>  Douglas E. Engert  <DEEngert at gmail.com> <DEEngert at gmail.com>
>
>
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160120/0ed6fea4/attachment-0001.html>