Hi Uri, Sorry, took a while to respond to your request. I cloned "https://github.com/OpenSC/libp11.git" and looked into it for some time. It is really hard for me to give you any advice without knowing the code and/or trying to debug it. My only observation is going back to my previous comment about the new EC_generate_key() function that I was adding into the openssl 1.0.2 patch. If you do not add it (and I didn't see it added to your code) then the OpenSSL TLS1.2 protocol (not sure about previous protocols) will send out to the client a software-generated ephemeral public key: it happens early in the exchange before the "ECDH_compute_key()" function is called. Of course it does not matter if you are using just OpenSSL ephemeral keys (not hardware-generated). I hope it will help.
Regards, Alex. 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? > > 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. :-) > > > On 1/20/2016 2:19 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > Very possible that I'm missing the point here. > > 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. > > 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. > > 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? > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Douglas E Engert > *Sent: *Wednesday, January 20, 2016 14:59 > *To: *openssl-dev@openssl.org > *Reply To: *openssl-dev@openssl.org > *Subject: *Re: [openssl-dev] ECDH engine > >
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev