<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><tt>On 05/02/2015 00:42, Salz, Rich
        wrote:</tt><br>
    </div>
    <blockquote
cite="mid:453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">Yup.  Pretty empty.  Over the coming year there will be more.
</pre>
      <blockquote type="cite">
        <pre wrap="">I fear that this is an indication that you will be killing
off all the other non-EVP entrypoints in libcrypto
</pre>
      </blockquote>
      <pre wrap="">Yes there is a good chance of that happening.
</pre>
      <blockquote type="cite">
        <pre wrap="">, making
it much harder to use the library with experimental or
non-standard algorithms and methods.
</pre>
      </blockquote>
      <pre wrap="">
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.
</pre>
    </blockquote>
    <tt>You seem to misunderstand the scenario:</tt><tt><br>
    </tt><tt><br>
    </tt><tt>My scenario is:</tt><tt><br>
    </tt><tt><br>
    </tt><tt>1. Load an unchanged shared libcrypto.so.1.1 provided by an<br>
        OS distribution.</tt><tt><br>
    </tt><tt><br>
    </tt><tt>2. Implement / use / experiment with non-standard methods<br>
        (such as new modes of operation or new zero-knowledge<br>
        proofs) by calling the functions that are exported by<br>
        libcrypto out of the box.  The higher level libssl is<br>
        not used for anything.</tt><tt><br>
    </tt><tt><br>
    </tt><tt>Your scenario is:</tt><tt><br>
    </tt><tt><br>
    </tt><tt>1. Extend the higher level stuff (TLS1.2, CMS etc.) with
      non-<br>
        standard methods (such as new modes of operation or new<br>
        signature forms).</tt><tt><br>
    </tt><tt><br>
    </tt><tt>2. Inject this new functionality into existing applications<br>
        that use OpenSSL in generic ways, such as wget and WebKit<br>
        browsers.</tt><tt><br>
    </tt><tt><br>
    </tt><tt>My scenario got great advantages from the large number of<br>
      fundamental interfaces exported from libcrypto.so.1.0 and<br>
      will automatically benefit when a new patch release of<br>
      OpenSSL is installed on the system (e.g. to fix a timing<br>
      attack on one of the algorithm implementations).  Having<br>
      to create a custom libnotquitecrypto.so.1.1 would not do<br>
      this, and distributing such a library as source patches<br>
      became much harder when you reformatted the source.</tt><tt><br>
    </tt><tt><br>
    </tt><tt>Looking at the reverse dependencies in Debian, the<br>
      following</tt><tt> projects probably use low level libcrypto<br>
      interfaces to do interesting things: afflib, asterisk,<br>
      bind, clamav, crda (WiFi), crtmpserver, encfs, ewf-tools,<br>
      faifa (Ethernet over Power), gfsd, gnugk, gnupg-pkcs11-scd,<br>
      hfsprogs, hostapd (WiFi), ipppd, KAME IPSEC, OpenBSD IPSEC,<br>
      ldnsutils, apache mod-auth-cas, apache mod-auth-openid,<br>
      perl's Crypt::OpenSSL::Bignum, libh323, liblasso, barada,<br>
      StrongSWAN, unbound, libxmlsec, libzrtpcpp, nsd, opensc,<br>
      openssh, rdd, rdesktop, rsyncrypto, samdump, tor,<br>
      tpm-tools, trousers, wpasupplicant (WiFi), yate, zfs-fuse.<br>
      *This is only a rough list based on features claimed by<br>
      OpenSSL-depending packages*<br>
      <br>
    </tt>
    <blockquote
cite="mid:453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ?
</pre>
      </blockquote>
      <pre wrap="">
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.     
</pre>
    </blockquote>
    <tt>I believe you have made the mistake of discussing only amongst<br>
      yourselves, thus gradually convincing each other of the<br>
      righteousness of a flawed decision.</tt><tt><br>
      <br>
    </tt>
    <pre class="moz-signature" cols="72">Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
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 </pre>
  </body>
</html>