[openssl-dev] ECDH engine

Wed Jan 20 20:29:04 UTC 2016

On Wed, Jan 20, 2016 at 11:34 AM, Blumenthal, Uri - 0553 - MITLL <
uri at 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 <
> 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
>> *Reply To: *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
>> *Reply To: *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,
>> 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
>> *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 <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
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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/2b519448/attachment-0001.html>