Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
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
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.
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 <
[email protected]>
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
Subject: Re:
[openssl-dev] ECDH engine
|
Your comments are welcome.
Regards,
Alex.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
--
Douglas E. Engert <[email protected]>
