On 05/02/2015 00:42, Salz, Rich wrote: >> 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. You seem to misunderstand the scenario: My scenario is: 1. Load an unchanged shared libcrypto.so.1.1 provided by an OS distribution. 2. Implement / use / experiment with non-standard methods (such as new modes of operation or new zero-knowledge proofs) by calling the functions that are exported by libcrypto out of the box. The higher level libssl is not used for anything. Your scenario is: 1. Extend the higher level stuff (TLS1.2, CMS etc.) with non- standard methods (such as new modes of operation or new signature forms). 2. Inject this new functionality into existing applications that use OpenSSL in generic ways, such as wget and WebKit browsers. My scenario got great advantages from the large number of fundamental interfaces exported from libcrypto.so.1.0 and will automatically benefit when a new patch release of OpenSSL is installed on the system (e.g. to fix a timing attack on one of the algorithm implementations). Having to create a custom libnotquitecrypto.so.1.1 would not do this, and distributing such a library as source patches became much harder when you reformatted the source. Looking at the reverse dependencies in Debian, the followingprojects probably use low level libcrypto interfaces to do interesting things: afflib, asterisk, bind, clamav, crda (WiFi), crtmpserver, encfs, ewf-tools, faifa (Ethernet over Power), gfsd, gnugk, gnupg-pkcs11-scd, hfsprogs, hostapd (WiFi), ipppd, KAME IPSEC, OpenBSD IPSEC, ldnsutils, apache mod-auth-cas, apache mod-auth-openid, perl's Crypt::OpenSSL::Bignum, libh323, liblasso, barada, StrongSWAN, unbound, libxmlsec, libzrtpcpp, nsd, opensc, openssh, rdd, rdesktop, rsyncrypto, samdump, tor, tpm-tools, trousers, wpasupplicant (WiFi), yate, zfs-fuse. *This is only a rough list based on features claimed by OpenSSL-depending packages* >> 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. I believe you have made the mistake of discussing only amongst yourselves, thus gradually convincing each other of the righteousness of a flawed decision. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150206/28ca86f4/attachment.html>
