Hi Uri, On Wed, Jan 27, 2016 at 9:25 AM, Blumenthal, Uri - 0553 - MITLL < u...@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. :-) > > > >
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev