[crypto-discuss] SHA224 & binary compatibility in libmd

[Darren J Moffat]

When we initially added support for the FIPS 180-2 defined 
SHA256,SHA384,SHA512 we didn't also add SHA224 support.

Unfortunately the SHA2Init() function takes a uint64_t as the mechanism 
we are doing the Init() for.  Since these are just #define'd in 
<sys/sha2.h> they form not only part of the API but we can't change the 
numbering incompatibly as Bill points out here:

http://mail.opensolaris.org/pipermail/crypto-discuss/2007-January/000011.html

I believe I've come up with a way to preserve the binary compatibility 
of the SHA2*Init() functions and introduce SHA224 support without 
needing to give up on the <= > comparisons we do against the 
sha2_mech_type_t enumeration values in the more performance critical 
parts of the implementation.

I've done some basic testing using libmd (32 and 64 bit) with the test 
vectors from the RFC and it appears to work and preserve the binary 
compatibility as well and without sacrificing performance since the 
change is just in SHA2Init().

The sha2_mech_type_t is a private implementation detail between the 
sha2.c code and the code in kernel/crypto/sha2 and pkcs11_softtoken that 
uses those sha2_mech_type_t values.

In SHA2Init() we put the uint64_t mech value into the ctx for later use 
as alogtype where we do <= > and == comparisons against it.

I believe we can preserve the values of the uint64_t mech and add 3 for 
the SHA224 support at the "top" (ie they are 9,10,11) and have 
SHA2Init() remap these and store the appropraite sha2_mech_type_t.  The 
tick is in making the sha2_mech_type_t start outside the current 0-8 range.

I have a webrev ready for most of the SHA224 work here:

http://cr.grommit.com/~darrenm/sha224/webrev/

The key files too look at for just the binary compatibility part are:

usr/src/common/crypto/sha2/sha2.c
usr/src/uts/common/sys/sha2.h


It doesn't yet include the changes for pkcs11_softtoken or the dprov 
changes.  The changes for libmd and kernel/cryoto/sha2 should be 
complete.  In order to do pkcs11_softtoken I need to get the PKCS#11 
pkcs11t.h header file updated first.


Does this look okay to people as a way to implement SHA224 and keep our 
binary compat without giving up the comparisons we do on the enum values  ?

-- 
Darren J Moffat