[secdir] Review of draft-eastlake-sha2b-06

[Tero Kivinen <[e-mail]>]

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document contains c-source code for the SHA1, SHA224, SHA256,
SHA384, and SHA512 for just hash functions, hmac functions and HKDF
functions. It also contains description of SHA224, SHA256, SHA384, and
SHA512 algorithms.

I did review the whole document including the code review on the
actual library functions. I did skip most of the test driver code
while doing code review. I also tested that the code include compiles,
and produced correct results in my system. I did this by comparing the
results from the functions in the draft and our own crypto library
implementation. As our library does not support inputs that are not
multiple of 8 bits, I did not verify the XXXFinalBits implementations
against external implementation.

Security consideration section say:

----------------------------------------------------------------------
   This document is intended to provide convenient open source access by
   the Internet community to the United States of America Federal
   Information Processing Standard Secure Hash Algorithms (SHAs) [FIPS
   180-2], HMACs based thereon, and HKDF. No independent assertion of
   the security of these functions by the authors for any particular use
   is intended.
----------------------------------------------------------------------

On the other hand the C-source files has following security related
statements:

----------------------------------------------------------------------
 *      The SHA-1 algorithm produces a 160-bit message digest for a
 *      given data stream.  It should take about 2**n steps to find a
 *      message with the same digest as a given message and
 *      2**(n/2) to find any two messages with the same digest,
 *      when n is the digest size in bits.  Therefore, this
 *      algorithm can serve as a means of providing a
 *      "fingerprint" for a message.
----------------------------------------------------------------------

which do give some assertion of the security of the functions. On the
other hand the statement in the SHA1.c might even be incorrect, as I
think there are attacks now that can find collisions in 2^69 steps
instead of 2^80 steps
(http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html).
There might be even faster attacks by now.

----------------------------------------------------------------------

Some other nits:

In section 3:

> 3. Operations on Words
...
>
>   d. The rotate right (circular right shift) operation ROTR^n(x), where
>        x is a w-bit word and n is an integer with 0 <= n < w, is
>        defined by
>
>             ROTR^n(x) = (x>>n) OR (x<<(w-n))
>
>   e. The rotate left (circular left shift) operation ROTL^n(x), where x
>        is a w-bit word and n is an integer with 0 <= n < w, is defined
>        by
>
>             ROTL^n(X)  =  (x<<n) OR (x>>w-n)
				          ^^^

Could also use "(w-n)" instead of "w-n" just to make sure of the
precedence. 

--

When compiling shatest.c on NetBSD 5.99.39 I do get following
warnings:

----------------------------------------------------------------------
shatest.c: In function 'unhexStr':
shatest.c:1312: warning: array subscript has type 'char'
shatest.c:1320: warning: array subscript has type 'char'
shatest.c: In function 'scasecmp':
shatest.c:1522: warning: array subscript has type 'char'
shatest.c:1523: warning: array subscript has type 'char'
----------------------------------------------------------------------

This is because shatest.c gives char directly to the tolower which is
macro in NetBSD. The unhexStr and scasecmp functions should do the
similar "(int)(unsigned char)" cast before giving *hexstr/*s1/*s2 to
tolower.
-- 
[e-mail]