<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.
<br>
OpenSSL approach to support this is OpenSSL-1.1 that does a lot of
other things. But that was there approach. Its their package.<br>
From working package to distribution always takes several years...<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/20/2016 1:34 PM, Blumenthal, Uri -
0553 - MITLL wrote:<br>
</div>
<blockquote cite="mid:D2C549BC.25B06%25uri@ll.mit.edu" type="cite"><span
id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"
style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0
0 0 5;">
<div>
<div>
<div dir="ltr">Probably it was one of the main reasons why
we didn't use pkcs11 for ATECC508A and wrote an engine
instead</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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 <span
style="font-weight: bold;">many</span> more of us in this bus,
on different OS (e.g., it looks like Ubuntu is even worse off
than Macports).</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"
style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0
0 0 5;">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Jan 20, 2016 at 11:10
AM, Blumenthal, Uri - 0553 - MITLL
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:uri@ll.mit.edu" target="_blank">uri@ll.mit.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"
style="background-color:rgb(255,255,255);line-height:initial">
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
Are you saying it won't work on
OpenSSL_1_0_2-stable?!</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
</div>
<div
style="font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.</div>
<table
style="background-color:white;border-spacing:0px"
width="100%">
<tbody>
<tr>
<td colspan="2"
style="font-size:initial;text-align:initial;background-color:rgb(255,255,255)">
<div style="border-style:solid none
none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt
0in 0in;font-family:Tahoma,'BB Alpha
Sans','Slate Pro';font-size:10pt">
<div><b>From: </b>Douglas E Engert</div>
<div><b>Sent: </b>Wednesday, January
20, 2016 14:07</div>
<div><b>To: </b><a
moz-do-not-send="true"
href="mailto:openssl-dev@openssl.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Reply To: </b><a
moz-do-not-send="true"
href="mailto:openssl-dev@openssl.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Subject: </b>Re:
[openssl-dev] ECDH engine</div>
</div>
</td>
</tr>
</tbody>
</table>
<br>
<div style="background-color:rgb(255,255,255)">Patches
are underdevelopment for OpenSC's libp11 and
engine_pkcs11 to support ECDH. There are
waiting for OpenSSL-1.1 to be come stable<br>
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<br>
to use ECDH from an external engine i.e. the
OPenSC engine_pkcs11. <br>
<br>
<a moz-do-not-send="true"
href="https://github.com/OpenSC/libp11/issues/52"
target="_blank">https://github.com/OpenSC/libp11/issues/52</a><br>
<a moz-do-not-send="true"
href="https://github.com/dengert/libp11/tree/prep-openssl-1.1"
target="_blank">
https://github.com/dengert/libp11/tree/prep-openssl-1.1</a><br>
<a moz-do-not-send="true"
href="https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1"
target="_blank">
https://github.com/dengert/engine_pkcs11/tree/prep-openssl-1.1</a><br>
<br>
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,
<br>
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.
<br>
<br>
Although OpenSC could still use an older
version of OpenSSL, there is also underway
changes for OpenSC to use OpenSSL-1.1:<br>
<a moz-do-not-send="true"
href="https://github.com/OpenSC/OpenSC/pull/654"
target="_blank">https://github.com/OpenSC/OpenSC/pull/654</a><br>
<a moz-do-not-send="true"
href="https://github.com/dengert/OpenSC/tree/prep-openssl-1.1"
target="_blank">https://github.com/dengert/OpenSC/tree/prep-openssl-1.1</a><br>
<br>
<br>
<div>On 1/20/2016 12:02 PM, Blumenthal, Uri -
0553 - MITLL wrote:<br>
</div>
<blockquote type="cite">
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
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).</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
OpenSC tools successfully derive (i.e.,
implement ECDH1_DERIVE). I'm waiting for
libp11 and engine_pkcs11 to add this
capability.</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
Ideally this is where your code would plug
in, and complete the circle.</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
As it currently is, a separate
Atmel-specific ECC-specific engine is of a
limited usefulness.</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
</div>
<div
style="font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.</div>
<table
style="background-color:white;border-spacing:0px"
width="100%">
<tbody>
<tr>
<td colspan="2"
style="font-size:initial;text-align:initial;background-color:rgb(255,255,255)">
<div>
<div><b>From: </b>Blumenthal, Uri
- 0553 - MITLL</div>
<div><b>Sent: </b>Wednesday,
January 20, 2016 12:46</div>
<div><b>To: </b><a
moz-do-not-send="true"
href="mailto:openssl-dev@openssl.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Reply To: </b><a
moz-do-not-send="true"
href="mailto:openssl-dev@openssl.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Subject: </b>Re:
[openssl-dev] ECDH engine</div>
</div>
</td>
</tr>
</tbody>
</table>
<br>
<div><span>
<blockquote style="border-left:#b5c4df 5
solid;padding:0 0 0 5;margin:0 0 0 5">
<div>
<div dir="auto">
<div>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. </div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>I see, thanks.</div>
<div><br>
</div>
<span>
<blockquote style="border-left:#b5c4df 5
solid;padding:0 0 0 5;margin:0 0 0 5">
<div>
<div dir="auto">
<div>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). </div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>There are a few hardware tokens
(USB-pluggable), e.g. Yubikey, that
support ECC256 and (in case of Yubikey
4) ECC384.</div>
<div><br>
</div>
<span>
<blockquote style="border-left:#b5c4df 5
solid;padding:0 0 0 5;margin:0 0 0 5">
<div>
<div dir="auto">
<div>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.</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Here’s the PKCS#11 spec <a
moz-do-not-send="true"
href="http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf"
target="_blank"><a class="moz-txt-link-freetext" href="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</a></a>,
which covers ECDH including ECDH1_DERIVE
and ECDH1<span style="font-style:italic">_</span>COFACTOR_DERIVE.
I think older versions (like v2.20) have
more content, but this is the current
one.</div>
<div><br>
</div>
<div>Hope it helps.</div>
<div><br>
</div>
<div>P.S. At this time I’m standing by my
original opinion – that a better way is
incorporating ECDH1_<span
style="font-style:italic">*</span>DERIVE
in libp11 and engine<span
style="font-style:italic">_</span>pkcs11,
rather than creating an engine
specifically for one chip that add
uncertainly of non-interoperability with
other chips/tokens.</div>
<div><br>
</div>
<div><br>
</div>
<span>
<blockquote style="border-left:#b5c4df 5
solid;padding:0 0 0 5;margin:0 0 0 5">
<div>
<div dir="auto">
<div>On Jan 20, 2016, at 8:11 AM,
Blumenthal, Uri - 0553 - MITLL
<<a moz-do-not-send="true"
href="mailto:uri@ll.mit.edu"
target="_blank">uri@ll.mit.edu</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
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?</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
I am trying to figure why
such a generic and useful
set of ECC operations (Sign,
Derive) is
implementation-limited to
one single
<whatever>. </div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
A much better solution to me
would be adding EC-DERIVE to
engine_pkcs11, and
automatically get all the
tokens covered.</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
Since I'm probably missing
something, could you please
educate me?</div>
<div
style="width:100%;font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br>
</div>
<div
style="font-size:initial;font-family:Calibri,'Slate
Pro',sans-serif;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.</div>
<table
style="background-color:white;border-spacing:0px"
width="100%">
<tbody>
<tr>
<td colspan="2"
style="font-size:initial;text-align:initial;background-color:rgb(255,255,255)">
<div>
<div><b>From: </b>Alexander
Gostrer</div>
<div><b>Sent: </b>Wednesday,
January 20, 2016
10:47</div>
<div><b>To: </b>Dr.
Stephen Henson</div>
<div><b>Reply To: </b><a
moz-do-not-send="true" href="mailto:openssl-dev@openssl.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Cc: </b><a
moz-do-not-send="true" href="mailto:openssl-dev@openssl.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></a></div>
<div><b>Subject: </b>Re:
[openssl-dev] ECDH
engine</div>
</div>
</td>
</tr>
</tbody>
</table>
<br>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>Hi Steve,<br>
</div>
And here is the
ENGINE
implementation for
Atmel ATECC508A with
few small patches to
OpenSSL_1_0_2-stable:<br>
<a
moz-do-not-send="true"
href="https://github.com/AtmelCSO/cryptoauth-openssl-engine"
target="_blank"><a class="moz-txt-link-freetext" href="https://github.com/AtmelCSO/cryptoauth-openssl-engine">https://github.com/AtmelCSO/cryptoauth-openssl-engine</a></a><br>
<br>
</div>
Your comments are
welcome.<br>
<br>
</div>
Regards,<br>
</div>
Alex.<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Sat, Dec 19, 2015 at
12:49 PM, Dr. Stephen
Henson <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:steve@openssl.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:steve@openssl.org">steve@openssl.org</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
On Fri, Dec 18,
2015, Alexander
Gostrer wrote:<br>
<br>
> Hi Steve,<br>
><br>
> John and I
completed writing an
ECDH engine based on
the<br>
>
OpenSSL_1_0_2-stable
branch. We were
planning to expand
it to the master<br>
> but found some
major changes made
by you recently.
What is the status
of<br>
> this task? Is
it stable enough to
follow it? Are you
planning another<br>
> changes? Is
there a design
document that we can
use in our work?<br>
><br>
<br>
The version in
master shouldn't
change much any
more. Documentation
will be<br>
available in the
near future. The
changes were meant
to remove some of
the<br>
weird "quirks" of
ECC compared to
other algortihms and
to permit future<br>
expansion to a wider
range of curves.<br>
<br>
In the meantime it
shouldn't be too
hard to follow how
the new code works.<br>
Instead of separate
ECDH/ECDSA methods
with weird locking
and ex_data and<br>
minimal ENGINE
support everything
is combined into a
single EC_KEY_METHOD<br>
which can contain
ECDSA, ECDH and key
generation
(something which was<br>
impossible with the
old code) and be
tied directly to an
ENGINE.<br>
<br>
Most of the primary
APIs such as
ECDH_compute_key can
be redirected
directly<br>
through an engine
supplied function in
EC_KEY_METHOD.<br>
<br>
Having said that the
code is very new and
may have the odd bug
that needs to<br>
be fixed. If you
have any problems
let me know and I'll
look into them.<br>
<br>
Steve.<br>
--<br>
Dr Stephen N.
Henson. OpenSSL
project core
developer.<br>
Commercial tech
support now
available see: <a
moz-do-not-send="true"
href="http://www.openssl.org" rel="noreferrer" target="_blank">
<a class="moz-txt-link-freetext" href="http://www.openssl.org">http://www.openssl.org</a></a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>openssl-dev mailing list</span><br>
<span>To unsubscribe: <a
moz-do-not-send="true"
href="https://mta.openssl.org/mailman/listinfo/openssl-dev"
target="_blank">
<a class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</a></a></span><br>
</div>
</blockquote>
</div>
</div>
</blockquote>
</span><br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
openssl-dev mailing list
To unsubscribe: <a moz-do-not-send="true" href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><span class="HOEnZb"></span></pre>
<span class="HOEnZb"></span></blockquote>
<span class="HOEnZb"><font color="#888888"><br>
<pre cols="200">--
Douglas E. Engert <a moz-do-not-send="true" href="mailto:DEEngert@gmail.com" target="_blank"><DEEngert@gmail.com></a>
</pre>
<br>
</font></span></div>
</div>
<br>
_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a moz-do-not-send="true"
href="https://mta.openssl.org/mailman/listinfo/openssl-dev"
rel="noreferrer" target="_blank">
https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
openssl-dev mailing list
To unsubscribe: <a class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="200">--
Douglas E. Engert <a class="moz-txt-link-rfc2396E" href="mailto:DEEngert@gmail.com"><DEEngert@gmail.com></a>
</pre>
</body>
</html>