[openssl-users] The evolution of the 'master' branch

[Jakob Bohm]

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>