I think Jakob?s real concern (as expressed to me off-list a month or so ago) is that OpenSSL?s libcrypto will become entirely hidden. I found several of his comments confusing until he mentioned that. So, I think the fair question to be asking is: Is there any plan to make libcrypto go completely opaque, such that _only_ the APIs exposed in libssl will be available? Thanks! TOM > On Feb 6, 2015, at 11:03 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote: > > 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 > following projects 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 > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
