[openssl-dev] ECDH engine

[Alexander Gostrer]

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/74ee0d34/attachment-0001.html>