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

Tero Kivinen <kivinen@iki.fi> Fri, 21 January 2011 14:07 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9D83A699D; Fri, 21 Jan 2011 06:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level:
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNGVehkTVETb; Fri, 21 Jan 2011 06:07:55 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDC23A6998; Fri, 21 Jan 2011 06:07:54 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p0LEAbF1002374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 16:10:37 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p0LEAaFv000109; Fri, 21 Jan 2011 16:10:36 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19769.37852.869585.298102@fireball.kivinen.iki.fi>
Date: Fri, 21 Jan 2011 16:10:36 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 17 min
X-Total-Time: 23 min
Cc: draft-eastlake-sha2b.all@tools.ietf.org
Subject: [secdir] Review of draft-eastlake-sha2b-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jan 2011 14:07:56 -0000

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.
-- 
kivinen@iki.fi