> Ø 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. > > > It’s a new feature, so it won’t come from OpenSSL. Don’t know if that’s an > issue or not. Only fixes go into released branches.
I see several lines of reasoning in favor of my approach: 1. It is more of a bug than of a new feature: OpenSSL-1.0 has been supporting ECC for quite a while. It also has been supporting engines (such as engine_pkcs11), and has mechanisms to specify that the keys are on the engine-accessible token. The fact that these mechanisms are half-done means to be that it’s a bug in need of fixing. As examples of new feature I’d consider EdDSA, or (if somebody decides to contribute it) Grasshopper for symmetric crypto library. 2. OpenSSL_1_0_2-stable (1.0.2f) has not yet been released. So even if you’re inclined to consider this a “feature” (even though it merely repairs previous undocumented deficiency), perhaps it can go in. Nobody is talking about fitting this fix into 1.0.2e or earlier (“really released” versions). I urge OpenSSL developers to consider this.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
