<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div bgcolor="#FFFFFF" text="#000000">When I started to write the ECDSA code for engine_pkcs11 in 2011 the code to support the method hooks was not<br>
in the code. So I used internal OpenSSL header files to copy the ECDSA_METHOD and replace the function needed.
<br>
Look for "BUILD_WITH_ECS_LOCL_H" in libp11. Not until 1.0.2 did OpenSSL support the needed calls to hook ECDSA.<br>
They did not add the hooks for ECDH. </div></div></blockquote></span><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">I am missing one thing here. Hopefully you can help me understanding it.</div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">OpenSSL-1.0.2 currently supports ECDH, as I observe by running</div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><p style="margin: 0px; font-size: 16px; font-family: Monaco; color: rgb(41, 249, 20); background-color: rgb(0, 0, 0);">openssl pkeyutl -derive -inkey /tmp/derive.29494.priv.pem -peerkey /tmp/derive.29494.token.pub.pem -out /tmp/derive.29494.shared1</p></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">So clearly there is working code available inside OpenSSL that does what is needed. The only issue then is to add code to libp11 to access that code. </div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">Am I correct? If not, could you please point at where/what I’m mistaken in?</div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div bgcolor="#FFFFFF" text="#000000">If you can't wait then you have to do it your self. *YOU* could do the same thing for ECDH. But your code would only
<br>
be good for 1.0.2 because the whole way of doing EC methods changes in 1.1. </div></div></blockquote></span><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">That’s perfectly OK, because if my tea leaves reading is correct, OpenSSL-1.0.2 will be around for several years at least. And most of the package providers such as Macports won’t move their packages to OpenSSL-1.1 for probably that long. So making 1.0.2 working with ECDH now will definitely make sense for me.</div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">In fact, I think making libp11 compliant with OpenSSL-1.1 <span style="font-weight: bold;">now</span> is an overreach, because this effort (unlike work on 1.0.2) is highly unlikely to bring benefits to users for a few years. </div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div bgcolor="#FFFFFF" text="#000000">I believe Alexander said he had changes to OpenSSL, which is another approach. <br>
He has said there were here: <a class="moz-txt-link-freetext" href="https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches">
https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches</a></div></div></blockquote></span><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div><font face="Calibri,sans-serif" style="color: rgb(0, 0, 0); font-size: 14px;">I see that the actual patch is very small. And the only meaningful (for me) change is adding a new method </font><font face="Consolas" style="color: rgb(0, 0, 0); font-size: 14px;">EC_generate<span style="font-style: italic;">_</span>key()</font><font face="Calibri,sans-serif">. I would like to understand why this method is needed – is it only to allow OpenSSL to <u>generate</u> key pair on the token? Alexander, could you comment please?</font></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div bgcolor="#FFFFFF" text="#000000">You could also hire someone who could do more then: "test it and offer minor enhancements".</div></div></blockquote></span><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">First, I cannot. Second, I don’t think (and haven’t seen any evidence to the contrary yet) that anything more <span style="font-weight: bold;">is</span> needed. Especially seeing the minuscule amount of changes Alexander had to do to OpenSSL, and I’m not even sure I need those if I don’t insist on being able to generate new key pair on the token using only OpenSSL.</div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div bgcolor="#FFFFFF" text="#000000">(And not me. I am taking the 1.1 approach to getting ECDH. working in engine.) </div></div></blockquote></span><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">:-) OK, I withdraw my unexpressed and unformulated offer. Consider yourself un-asked. :-)</div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><div style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><br></div><span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div bgcolor="#FFFFFF" text="#000000">On 1/20/2016 2:19 PM, Blumenthal, Uri - 0553 - MITLL wrote:<br><blockquote cite="mid:20160120201925.17788998.82513.46556@ll.mit.edu" 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);">
Very possible that I'm missing the point here.</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);">
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.</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);">
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.</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);">
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?</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:59</div><div><b>To: </b><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></div><div><b>Reply To: </b><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></div><div><b>Subject: </b>Re: [openssl-dev] ECDH engine</div></div></td></tr></tbody></table>
<br><div id="_originalContent" style="background-color: rgb(255, 255,
255);">
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 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">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="">Are you saying it won't work on OpenSSL_1_0_2-stable?!</div><div style=""><br></div><div style="">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=""><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" class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org"></a><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></div><div><b>Reply To: </b><a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org"></a><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</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="">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=""><br></div><div style="">OpenSC tools successfully derive (i.e., implement ECDH1_DERIVE). I'm waiting for libp11 and engine_pkcs11 to add this capability.</div><div style=""> </div><div style="">Ideally this is where your code would plug in, and complete the circle.</div><div style=""><br></div><div style="">As it currently is, a separate Atmel-specific ECC-specific engine is of a limited usefulness.</div><div style=""><br></div><div style="">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" class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org"></a><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></div><div><b>Reply To: </b><a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org"></a><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</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" class="moz-txt-link-freetext" href="http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf" target="_BLANK"></a><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>,
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"></a><a class="moz-txt-link-abbreviated" href="mailto:uri@ll.mit.edu">uri@ll.mit.edu</a>> wrote:<br><br></div><blockquote type="cite"><div><div style="">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=""><br></div><div style="">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=""><br></div><div style="">A much better solution to me would be adding EC-DERIVE to engine_pkcs11, and automatically get all the tokens covered.</div><div style=""><br></div><div style="">Since I'm probably missing something, could you please educate me?</div><div style=""><br></div><div style="">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" class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org"></a><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</a></div><div><b>Cc: </b><a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org"></a><a class="moz-txt-link-abbreviated" href="mailto:openssl-dev@openssl.org">openssl-dev@openssl.org</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" class="moz-txt-link-freetext" href="https://github.com/AtmelCSO/cryptoauth-openssl-engine" target="_BLANK"></a><a class="moz-txt-link-freetext" href="https://github.com/AtmelCSO/cryptoauth-openssl-engine">https://github.com/AtmelCSO/cryptoauth-openssl-engine</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" class="moz-txt-link-abbreviated" href="mailto:steve@openssl.org"></a><a class="moz-txt-link-abbreviated" href="mailto:steve@openssl.org">steve@openssl.org</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><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.openssl.org" target="_BLANK"></a><a class="moz-txt-link-freetext" href="http://www.openssl.org">http://www.openssl.org</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><a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_BLANK"></a><a class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</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"><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>_______________________________________________
openssl-dev mailing list
To unsubscribe: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_BLANK">https://mta.openssl.org/mailman/listinfo/openssl-dev</a></pre></blockquote><br><pre class="moz-signature" cols="200">--
Douglas E. Engert <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:DEEngert@gmail.com"><DEEngert@gmail.com></a>
</pre><br><!--end of _originalContent --></div><br><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></div></div></blockquote></span></body></html>