Re: SHA, MD, and openssl

[Pádraig Brady]

On 12/11/2013 06:54 PM, Paul Eggert wrote:
> [Adding bug-gnulib to CC.  This discussion no longer directly affects
> Emacs, since I removed the libcrypto support from Emacs yesterday
> <http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/115454>.  Gnulib
> still has support for linking to libcrypto, though, so it's still
> relevant for gnulib.  This email thread starts at
> <http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00252.html>.]

coreutils still enables use of openssl libcrypto where available.
I suspect this is more of an advantage to coreutils than to emacs,
due to the provision of bulk data processing functionality through
md5sum and sha1sum etc.

> On 12/11/2013 07:13 AM, Richard Stallman wrote:
> 
>> I don't think OpenSSL is included in the normal form of
>> packaging Linux
> 
> I'm afraid you've lost me.  Did you mean that Linux is the "Major
> Component" as described in the GPL?  If so, that doesn't sound right,
> as the code we're talking about is crypto hash code, which doesn't
> need to interface to the Linux kernel at all.  It's written in pure
> C and/or assembly code, with no Linux system calls.
> 
> The Major Component here is not the Linux kernel; it's cryptographic
> services, which these days are a major essential component of many
> operating systems, including common GNU/Linux distributions.
> Obviously one can build a GNU/Linux system without crypto, just as one
> can build one without a windowing system, but nevertheless crypto is a
> major essential component for many systems, just as windowing is.
> 
>> I don't think it satisfies (b) either.
> 
> I don't see why not, for the crypto hash functions we're talking
> about.  MD5, SHA256, etc. are all interfaces that are official
> standards defined by recognized standards bodies, and implementations
> for them are available to the public in source code form.

So practically I see the openssl crypto libs as ubiquitous and the chosen
interface used to expose _system_ specific checksum functionality,
down to specific sha instructions or coprocessing units etc.
I don't see using these interfaces as detrimental to the essential freedoms,
but instead _significantly_ improving the performance and thus the
utility of these core GNU tools. If we don't use these system interfaces
we'll just be sidelined for something that does.

Now we could clean room implement equivalent operations for the many disparate
systems out there, however it's worth noting there is significant advantage in
hardware vendors consolidating around a single implementation, and openssl
is where that's at currently.  I'm not discounting that a GPL equivalent
might arise, but until that happens we should use the current system interfaces.
BTW openssl.org says it's OK to use these interfaces from GPL software
due to the system lib exception: http://www.openssl.org/support/faq.html#LEGAL2

thanks,
Pádraig.