[Cfrg] [Fwd: FIPS 180-2 and comments]

Marc Branchaud <marcnarc@rsasecurity.com> Fri, 06 September 2002 15:47 UTC

Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08566 for <cfrg-archive@odin.ietf.org>; Fri, 6 Sep 2002 11:47:10 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g86FmKn17368 for cfrg-archive@odin.ietf.org; Fri, 6 Sep 2002 11:48:20 -0400
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g86FmKX17365 for <cfrg-web-archive@optimus.ietf.org>; Fri, 6 Sep 2002 11:48:20 -0400
Received: from www1.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08482; Fri, 6 Sep 2002 11:46:40 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g86FldX17084; Fri, 6 Sep 2002 11:47:39 -0400
Received: from ietf.org (odin.ietf.org []) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g860P3t12205 for <cfrg@optimus.ietf.org>; Thu, 5 Sep 2002 20:25:03 -0400
Received: from sigurd.x509.com (nebula.x509.com []) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12405 for <cfrg@ietf.org>; Thu, 5 Sep 2002 20:23:20 -0400 (EDT)
Received: from nebula.x509.com by sigurd.x509.com via smtpd (for odin.ietf.org []) with SMTP; 6 Sep 2002 00:24:56 UT
Received: from crack.x509.com (mail.x509.com []) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g860OtF07545 for <cfrg@ietf.org>; Thu, 5 Sep 2002 17:24:55 -0700 (PDT)
Received: from rsasecurity.com (eskarina.eng.x509.com []) by crack.x509.com (8.11.6/XCERT) with ESMTP id g860OrN13992; Thu, 5 Sep 2002 17:24:53 -0700 (PDT)
Message-ID: <3D77F657.4040407@rsasecurity.com>
Date: Thu, 05 Sep 2002 17:27:03 -0700
From: Marc Branchaud <marcnarc@rsasecurity.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020905
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cfrg@ietf.org
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/mixed; boundary="------------000407000108060107080602"
Subject: [Cfrg] [Fwd: FIPS 180-2 and comments]
Sender: cfrg-admin@ietf.org
Errors-To: cfrg-admin@ietf.org
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>

Though I'm sure most folks here are subscribed to Perry Metzger's
cryptography list, this seems to have particular relevance to CFRG...

--- Begin Message ---
> National Institute of Standards and Technology
> [Docket No. 001214352-2097-02]
> Announcing Approval of Federal Information Processing Standard
> (FIPS) 180-2, Secure Hash Standard; a Revision of FIPS 180-1
> AGENCY: National Institute of Standards and Technology (NIST),
> Commerce.

FIPS 180-2 has been approved. This revision to the standard adds the 256, 
384, and 512 bit output hash algorithms. Included in the announcement was a 
section of comments on the standard and responses by NIST to the comments.

Of note...

>     Comment: One comment suggested that there may be weaknesses in the
> algorithms, and proposed a method to change the standard to address the
> perceived weaknesses.
>     Response: It would be more appropriate for the perceived weaknesses
> to be addressed in application standards such as the Federal
> Information Processing Standard for the Keyed-Hash Message
> Authentication Code (HMAC), which has been approved as FIPS 198, as
> opposed to addressing this in FIPS 180-2 itself. Furthermore, NIST
> expects to issue guidance on the implementation of secure hash
> functions.

The comments received on the standard are available on the NIST Computer 
Security Research Center (CSRC) web site (http://csrc.nist.gov) in a pdf 
(http://csrc.nist.gov/encryption/shs/dfips-180-2-comments1.pdf). That 
document contains the message by John Kelsey that discusses the "perceived" 
weakness being referred to in this comment.

The hash algorithms will not be tweaked to prevent this property. Besides 
being addressed in FIPS (and potentially other) standards that build upon 
these hash algorithms, guidance may be issued and it will then be left in 
the hands of implementers and standards developers. (I guess I am still 
struck by how RC4 was used in WEP.)

Is there any new (within 6 months) research on SHA-1, SHA-256, SHA-384, 
and/or SHA-512? Strengths, weaknesses, etc.? Pointers would be appreciated.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com

--- End Message ---