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

[Rich Felker <dalias at libc dot org>]

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.

I'm opposed to allocation/deallocation functions. They have no benefit
and make the API largely useless since you can't rely on it --
allocation could always fail, and then you're better off just writing
your own version of SHA2 that can't fail. Allocation also means you
can't use it in an async signal context.

> In any case, this needs much more discussion and research before we can
> commit to a stable API.

I agree. This is not something that should be rushed. If it's going to
be considered, there should be input from multiple libc implementors
(on multiple systems, e.g. also BSDs) as to how the API should work.
Otherwise it's just going to be something non-portable that nobody can
use (or worse, have different APIs/behaviors on different systems).

Rich