Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
"Hugo Krawczyk" <hugo@ee.technion.ac.il> Tue, 30 December 2008 23:40 UTC
Return-Path: <saag-bounces@ietf.org>
X-Original-To: saag-archive@ietf.org
Delivered-To: ietfarch-saag-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7005A28C31B; Tue, 30 Dec 2008 15:40:51 -0800 (PST)
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3359D28C31A for <saag@core3.amsl.com>; Tue, 30 Dec 2008 15:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.376
X-Spam-Level:
X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6]
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 klESOfBIOsva for <saag@core3.amsl.com>; Tue, 30 Dec 2008 15:40:48 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 0829028C2F6 for <saag@ietf.org>; Tue, 30 Dec 2008 15:40:47 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id 13so351051fge.41 for <saag@ietf.org>; Tue, 30 Dec 2008 15:40:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=DDpekhM52VkOAoRXt2PZCjhH4t1PiBNvOlzCNzEqzL4=; b=ZZz3YvRMqfdLQsd/8ahiFloECdUPBawdLeuuNZH8Cr46ZHYLNXsoZ+HMY+zLRX6zYI h+P2eWBjHI0CacQWPFxFZXccAWRnZLdIAa2ZIivutA9pgNYpKm9PZOVdbDda45599etK ntwcXzkHyb9uMG1+RTH91bwmHp47itVwiUsgY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=rIO56ncxno48IvUn931cZzc48cPja3c6sVugRkSlz07p+kL31iFVgv0xYSnUpIRGhc 9l8VIIu5uelDeSjEMvZMXmMvlH94d3yEPdueUvJdVnE1X+piIepre66GsXldcD7HYouL S1ChvvQEJXezzzv/SuiCz/3ifmbLVWzeW8SV8=
Received: by 10.86.95.20 with SMTP id s20mr2438156fgb.39.1230680436423; Tue, 30 Dec 2008 15:40:36 -0800 (PST)
Received: by 10.86.93.6 with HTTP; Tue, 30 Dec 2008 15:40:36 -0800 (PST)
Message-ID: <e89b43830812301540p17f5c0e2y961dcfa66b74dcf6@mail.gmail.com>
Date: Tue, 30 Dec 2008 18:40:36 -0500
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
To: Eric Rescorla <ekr@networkresonance.com>
In-Reply-To: <20081230213934.C219450822@romeo.rtfm.com>
MIME-Version: 1.0
References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <p0624081dc5802a331eac@10.20.30.158> <20081230213934.C219450822@romeo.rtfm.com>
X-Google-Sender-Auth: 51d21de5a352475d
Cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0993061957=="
Sender: saag-bounces@ietf.org
Errors-To: saag-bounces@ietf.org
Paul, Eric and everyone else, Paul said > > If the IETF feels that adding randomization to signatures is > important, we should define randomized signature functions. We could > start with NIST Draft SP 800-106 > (< http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>). However, > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. and Eric responded > I certainly agree we should be encouraging the use of non-broken hash > functions. However, randomizing the SN seems like very cheap backward > compatible insurance against the fact that that's going to take a long time. I believe that the best answer to the above arguments regarding the use of randomized hashing vs. the "patch" of using random SNs is given by Sotirov et al, the cryptanalysts that carried out the remarkable MD5-certificate attack (see their website). They say: *We do note however that this use of randomness in the serial number is a workaround, made possible by lucky choices in the X.509 standard. It is not a bad idea in general to add randomness to a hash input when a possible attacker is able to choose the input. A much more reliable, since designed, solution is to use randomized hashing, see [HK]. Such a solution introduces randomization as a "mode of operation" for hash functions, which is a much more fundamental approach to the problem than relying on features that happen to be present in existing standards for non-security reasons, or for no reason at all.* In this light, I disagree with Paul's statement: > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. The two things are not exclusive. We should do BOTH: Adopt a randomized hashing technique (as a mode of operation for hash functions) and continue our quest for better hash functions. We must aim at the best possible hash function, but we cannot guarantee its security in the long term. As stated in the above text by Sotirov et al, randomized hashing is a more fundamental (I would call it "infrastructural") approach. It strengthens digital signatures with any hash function and for any digital signature application, not just certificates. Let's take the example of HMAC: Its development in mid-90's was motivated to a large extent by the weaknesses found in MD5 by Dobbertin and others. If we took the approach of "let's use a better hash function" we should have adopted the key-append method MAC(K,X) = SHA1(X||K) which used SHA1 for which there was ample belief that it was a very good collision resistant hash function. However, had we done that, we would now have a broken MAC since the above design breaks with collisions on the underlying hash function. I believe that the responsible course of action for the IETF and particularly SAAG is to adopt the standardization process started by NIST with http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf and create a deployment path that could accommodate a randomized hashing approach as a mode of operation. This includes the consideration of randomized hashing in protocol changes and new protocol design that support algorithm agility. No one in the world will think that by doing that we should keep using MD5, or not pay attention to NIST's hash competition, or should stop from moving to SHA2. The just-published attack indicates that it is time that we take seriously our digital signatures, and randomized hashing is the best long-term insurance we know against future collision vulnerabilities. You can find more details on the specific randomized hashing approach behind NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/ In particular, some of the documents in that site provide some guidance regarding implementation and deployment issues (it also includes a now-expired internet draft). Hugo
_______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag
- [saag] Further MD5 breaks: Creating a rogue CA ce… Russ Housley
- Re: [saag] Further MD5 breaks: Creating a rogue C… Jeffrey Hutzelman
- Re: [saag] Further MD5 breaks: Creating a rogue C… Eric Rescorla
- Re: [saag] Further MD5 breaks: Creating a rogue C… Russ Housley
- Re: [saag] Further MD5 breaks: Creating a rogue C… Paul Hoffman
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Eric Rescorla
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Jeffrey Hutzelman
- Re: [saag] Further MD5 breaks: Creating a rogue C… Russ Housley
- Re: [saag] Further MD5 breaks: Creating a rogue C… Yoav Nir
- Re: [saag] Further MD5 breaks: Creating a rogue C… Russ Housley
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Eric Rescorla
- Re: [saag] Further MD5 breaks: Creating a rogue C… Russ Housley
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Eric Rescorla
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Nicolas Williams
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Jeffrey Hutzelman
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] Further MD5 breaks: Creating a rogue C… Santosh Chokhani
- Re: [saag] Further MD5 breaks: Creating a rogue C… Santosh Chokhani
- Re: [saag] Further MD5 breaks: Creating a rogue C… Santosh Chokhani
- Re: [saag] Further MD5 breaks: Creating a rogue C… Hugo Krawczyk
- Re: [saag] Further MD5 breaks: Creating a rogue C… Jeffrey Hutzelman
- Re: [saag] Further MD5 breaks: Creating a rogue C… Peter Gutmann
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Eric Rescorla
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] Further MD5 breaks: Creating a rogue C… RJ Atkinson
- Re: [saag] Further MD5 breaks: Creating a rogue C… Santosh Chokhani
- Re: [saag] Further MD5 breaks: Creating a rogue C… Vishwas Manral
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … RJ Atkinson
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Peter Gutmann
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Peter Gutmann
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Ben Laurie
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Eric Rescorla
- Re: [saag] RFC analyzing IETF use of hash functio… Sean Shen
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Paul Hoffman
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Ben Laurie
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Ben Laurie
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Robert Moskowitz
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Sean Shen
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Yoav Nir
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Paul Hoffman
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Yoav Nir
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Peter Gutmann
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Paul Hoffman
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Jeffrey Hutzelman
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Santosh Chokhani
- Re: [saag] Further MD5 breaks: Creating a rogue C… RL 'Bob' Morgan
- Re: [saag] Further MD5 breaks: Creating a rogue C… Peter Hesse
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Blake Ramsdell
- Re: [saag] Further MD5 breaks: Creating a rogue C… Scott Rea
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] Further MD5 breaks: Creating a rogue C… Timothy J. Miller
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Tim Moses
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Mike
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Richard Graveman
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Mike
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Dr Stephen Henson
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] Further MD5 breaks: Creating a rogue C… Philipp Guehring
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Mike
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Peter Hesse
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Weger, B.M.M. de
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Yoav Nir
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Yoav Nir
- Re: [saag] Further MD5 breaks: Creating a rogue C… der Mouse
- Re: [saag] Further MD5 breaks: Creating a rogue C… RJ Atkinson
- [saag] attacks on keyed-hash constructions [was: … David McGrew
- Re: [saag] attacks on keyed-hash constructions [w… RJ Atkinson
- [saag] RFC analyzing IETF use of hash functions [… David McGrew
- Re: [saag] [Cfrg] RFC analyzing IETF use of hash … Paul Hoffman
- Re: [saag] Further MD5 breaks: Creating a rogue C… Jeffrey Hutzelman
- Re: [saag] [Cfrg] RFC analyzing IETF use of hash … Vishwas Manral
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Stephen Kent
- Re: [saag] RFC analyzing IETF use of hash functio… Sean Turner
- Re: [saag] RFC analyzing IETF use of hash functio… David McGrew
- Re: [saag] [Cfrg] RFC analyzing IETF use of hash … David McGrew
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] [Cfrg] attacks on keyed-hash construct… Christian Rechberger
- Re: [saag] [Cfrg] RFC analyzing IETF use of hash … Ran Canetti
- Re: [saag] [Cfrg] Further MD5 breaks: Creating a … Timothy J. Miller
- Re: [saag] [Cfrg] RFC analyzing IETF use of hash … David McGrew
- Re: [saag] [Cfrg] RFC analyzing IETF use of hash … Joseph Salowey (jsalowey)