[openssl-dev] ECDH engine

Wed Feb 17 17:25:43 UTC 2016

Yea, my nice email server decided that it needed to re-send that piece. ;)

But there have been changes since our conversation in January. I’d greatly
appreciate if you could take a look at the current Github master of
openssl/libp11 (it now has subsumed engine_pkcs11, and integrated ECDH
support) and check if it alleviates the need for your ECDH engine.

-- 
Regards,
Uri Blumenthal

From:  openssl-dev <openssl-dev-bounces at openssl.org> on behalf of Alexander
Gostrer <agostrer at gmail.com>
Reply-To:  openssl-dev <openssl-dev at openssl.org>
Date:  Wednesday, February 17, 2016 at 11:32
To:  openssl-dev <openssl-dev at openssl.org>
Subject:  Re: [openssl-dev] ECDH engine

> Hi Uri,
> 
> On Wed, Jan 27, 2016 at 9:25 AM, Blumenthal, Uri - 0553 - MITLL
> <uri at ll.mit.edu> wrote:
>>> When I started to write the ECDSA code for engine_pkcs11  in 2011 the code
>>> to support the method hooks was not
>>> in the code. So I used internal OpenSSL header files to copy the
>>> ECDSA_METHOD  and replace the function needed.
>>> Look for "BUILD_WITH_ECS_LOCL_H" in libp11.  Not until 1.0.2 did OpenSSL
>>> support the needed calls to hook ECDSA.
>>> They did not add the hooks for ECDH.
>> 
>> I am missing one thing here. Hopefully you can help me understanding it.
>> 
>> OpenSSL-1.0.2 currently supports ECDH, as I observe by running
>> openssl pkeyutl -derive -inkey /tmp/derive.29494.priv.pem -peerkey
>> /tmp/derive.29494.token.pub.pem -out /tmp/derive.29494.shared1
>> 
>> 
>> 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.
>> 
>> Am I correct? If not, could you please point at where/what I’m mistaken in?
>> 
>>> 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
>>> be good for 1.0.2 because the whole way of doing EC methods changes in 1.1.
>> 
>> 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.
>> 
>> In fact, I think making libp11 compliant with OpenSSL-1.1 now is an
>> overreach, because this effort (unlike work on 1.0.2) is highly unlikely to
>> bring benefits to users for a few years.
>> 
>>> I believe Alexander said he had changes to OpenSSL, which is another
>>> approach. 
>>> He has said there were here:
>>> https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches
>> 
>> I see that the actual patch is very small. And the only meaningful (for me)
>> change is adding a new method EC_generate_key(). I would like to understand
>> why this method is needed – is it only to allow OpenSSL to generate key pair
>> on the token? Alexander, could you comment please?
>  
> I was already responding to it. Here is the copy-paste from my previous
> response:
> In the TLS-1.2 protocol (sl_srvr.c) the server generates an ephemeral key pair
> for ECDH and sends the public key in the server key exchange message (see
> ssl3_send_server_key_exchange(SSL *s) function). It does not use the private
> key until it gets the client public key in the
> "ssl3_send_server_key_exchange(SSL *s)". Just then it calls the
> "ECDH_compute_key()" with the client public key and the server private key
> generated much earlier. If I do not call this new function (EC_generate_key())
> then the openssl sends a software-generated ephemeral key to the client.
> Adding this function was the simplest way to fix the problem. On client
> everything happens in the same function so it wasn't a problem.
>  
>> 
>>> You could also hire someone who could do more then: "test it and offer minor
>>> enhancements".
>> 
>> First, I cannot. Second, I don’t think (and haven’t seen any evidence to the
>> contrary yet) that anything more is 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.
>> 
>>> (And not me. I am taking the 1.1 approach to getting ECDH. working in
>>> engine.) 
>> 
>> :-)  OK, I withdraw my unexpressed and unformulated offer. Consider yourself
>> un-asked.  :-)
>> 
>> 
>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160217/88ba0050/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160217/88ba0050/attachment-0001.bin>