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-boun...@openssl.org> on behalf of Alexander Gostrer <agost...@gmail.com> Reply-To: openssl-dev <openssl-dev@openssl.org> Date: Wednesday, February 17, 2016 at 11:32 To: openssl-dev <openssl-dev@openssl.org> Subject: Re: [openssl-dev] ECDH engine > 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. :-) >> >> >>>
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev