>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$
