Re: [PATCH] sha2: new header <sha2.h>

[Shawn Landden <shawn at churchofgit dot com>]

On Thu, Apr 02, 2015 at 12:22:28AM +0200, Florian Weimer wrote:
> On 03/28/2015 09:00 AM, Shawn Landden wrote:
> > Export the SHA2 family of functions in -lcrypt.
> > 
> > We already have these functions for crypt(), and many projects and spending much
> > effort reimplementing them. The most popular library, openSSL, also has infamous
> > licensing issues and is way overkill when AES is not needed. OpenSSL is the only
> > library I know of that support SHA2 cpu extensions as well.
> 
> I don't think this should go into libcrypt.  We might need it inside
> libc for a future PRNG.
> 
> The proposed API is likely incompatible with some forms of hardware
> acceleration.  I already told you that you need to add
> allocation/deallocation functions.  There is a reason why OpenSSL only
> provides hardware acceleration with the EVP API.
A allocation/deallocation scheme would certainly be required to use AF_ALG
for example (to get access to hardware acceleration that is only accesable to
kernel space), but unless the processor is really slow, or it is done
asyncronously that will almost assuredly be slower because of the context
switches (this wouldn't be the case with AES, but we are not implementing that)
, except in the special case of using it with sendfile (which has always
been broken). There is currently no way to know that AF_ALG hardware
acceleration is available, and I don't think AF_ALG should be used for hashes.
(it currently is only supported in OpenSSL by an out-of-tree module)

SHA256 only requires 32-bit alignment, and SHA512 64-bit alignment,
for the "real" part of the ctx. (H[8]) The buffers used in libcrypt are
already twice as large as they need to be, and hardware implementations are
free to not update ctx during large *update() calls, but only at the end.
Fully aligned update() calls will not use or access the buffer at all.
I really don't see allocate/deallocate functions as benificial.
> 
> In any case, this needs much more discussion and research before we can
> commit to a stable API.
> 
> -- 
> Florian Weimer / Red Hat Product Security