>Not much on that page so far, not even a "kill list" of
>intended victims except an admission that EAY's popular DES
>library can no longer be accessed via the copy in OpenSSL.
Yup. Pretty empty. Over the coming year there will be more.
>I fear that this is an indication that you will be killing
>off all the other non-EVP entrypoints in libcrypto
Yes there is a good chance of that happening.
>, making
> it much harder to use the library with experimental or
> non-standard algorithms and methods.
Well, not really much harder. I think that what DOES get harder is binary
distributions of such things, as opposed to custom OpenSSL builds that have
these new features. Don't forget, *you have the source* Hack away. Do what
you want. And having a standard API that any of your consumers use will
benefit your consumers greatly. And by making things like the EVP structure
hidden from your consumers, then you can add a new experimental crypto
mechanism and -- this is an important major benefit: THEIR CODE DOES NOT HAVE
TO RECOMPILE. As an implementor, your work is a bit harder. For your users,
it is much easier. Imagine being able to put an OID in a config file and
applications can almost transparently use any crypto available without change.
(Emphasis on ALMOST :) To us, this is clearly the right trade-off to make.
> Should everyone not doing just TLS1.2 move to a different library now, such
> as crypto++ ?
Use whatever works best for you, and your consumers/customers.
Not everyone will agree with this direction. Some people will be inconvenienced
and maybe even completely drop using OpenSSL. We discussed this pretty
thoroughly, and while we respect that some may disagree, please give us credit
for not doing this arbitrarily, or on a whim.
/r$
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
