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-open...@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 _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
