IETF Logo Mail Archive

Re: [Cfrg] Message Digest Algorithm Choice for CMS with Ed448

Derek Atkins <derek@ihtfp.com> Wed, 16 November 2016 16:56 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7611295CF for <cfrg@ietfa.amsl.com>; Wed, 16 Nov 2016 08:56:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7tOC4NfEomj for <cfrg@ietfa.amsl.com>; Wed, 16 Nov 2016 08:56:27 -0800 (PST)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABD0129560 for <cfrg@irtf.org>; Wed, 16 Nov 2016 08:56:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 83E6FE2042; Wed, 16 Nov 2016 11:56:19 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 11742-10; Wed, 16 Nov 2016 11:56:18 -0500 (EST)
Received: from securerf.ihtfp.org (unknown [IPv6:2001:470:e448:2:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id CE83BE203F; Wed, 16 Nov 2016 11:56:17 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1479315377; bh=e1GWUrXieYou5BqjCO3WCupAMBKZO11m+G3aec/kwtQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Ml3c76ADdQxaWMl07+YzFs0L6iglYwHLW67cKmOgBpdv0aFjnSNNUPktmOp0C+wHl Uq05jajwc1AFvE59/oGaONnJuxguHmMBhfIAR9w+88gqc8/pY7gJfU3xpGQ7Y2rETs 52k7WVshcL7V0Q+iVj3JN4m7yTWYVnlvRTxBcW2Q=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id uAGGuGEf011790; Wed, 16 Nov 2016 11:56:16 -0500
From: Derek Atkins <derek@ihtfp.com>
To: Taylor R Campbell <campbell+cfrg@mumble.net>
References: <20161114184709.B803D60380@jupiter.mumble.net>
Date: Wed, 16 Nov 2016 11:56:16 -0500
In-Reply-To: <20161114184709.B803D60380@jupiter.mumble.net> (Taylor R. Campbell's message of "Mon, 14 Nov 2016 18:47:20 +0000")
Message-ID: <sjm1sybs6rz.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ZgbUpVTmL43oBNqJm1oFWF_jQEc>
Cc: IRTF CFRG <cfrg@irtf.org>, Russ Housley <housley@vigilsec.com>, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Subject: Re: [Cfrg] Message Digest Algorithm Choice for CMS with Ed448
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 16:56:29 -0000

Taylor,

Taylor R Campbell <campbell+cfrg@mumble.net> writes:

>    Date: Mon, 14 Nov 2016 11:28:56 -0500
>    From: Derek Atkins <derek@ihtfp.com>
>
>    It depends which security service of signatures you're asking about.
>    For non-repudiation, yes, collision resistance is important.  However
>    preimage resistance is important for integrity/forging security.
>
> No!

Yes!  (two can play at that silly game -- I've got two toddlers who LOVE
to play that game).

> A signature scheme defined in terms of H(m), such as RSASSA-PSS,
> relies on the collision resistance of H to prevent forgery.  Preimage
> resistance is *not* sufficient.  Failure of MD5 to be collision-
> resistant is what enabled HTTPS certificate forgery in the wild ten
> years ago.

Ah, I see the confusion now...  We're using different definitions (and
processes) of forgery.

> (Attack: Find m =/= m' such that H(m) = H(m') and m is a certificate
> for for harmlessexample.com while m' is a certificate for google.com.
> Submit a CSR to a CA that you predict will issue m signed.  Now you
> have a signed certificate for google.com.)

In my mind this is a different kind of "non-repudiation" attack, not a
"forgery" attack.  In this case you're getting actual data signed, but
you're instead claiming (successfully, due to the collision) that you
got something else signed.  I.e., getting harmlessexample.com signed
isn't forging.  It's a valid signature on a valid certificate.  But
you're using a collision to effect a repudiation attack by claiming that
no, what was signed wasn't harmlessexample.com, but google.com.

It's a subtle but very important distinction (even if the end result is
the same -- a signed certificate for google.com)

[snip]
> Can we persuade the CURDLE WG to use an H(r, m) scheme instead, such
> as EdDSA without the prehash, and thereby dispel requirements of
> collision resistance?

Unlikely.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

v2.30.2 | Report a Bug | By Email | System Status