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

Derek Atkins <> Wed, 16 November 2016 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA7611295CF for <>; Wed, 16 Nov 2016 08:56:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R7tOC4NfEomj for <>; Wed, 16 Nov 2016 08:56:27 -0800 (PST)
Received: from (MAIL2.IHTFP.ORG []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DABD0129560 for <>; Wed, 16 Nov 2016 08:56:20 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83E6FE2042; Wed, 16 Nov 2016 11:56:19 -0500 (EST)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 11742-10; Wed, 16 Nov 2016 11:56:18 -0500 (EST)
Received: from (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 "", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by (Postfix) with ESMTPS id CE83BE203F; Wed, 16 Nov 2016 11:56:17 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 (8.15.2/8.14.8/Submit) id uAGGuGEf011790; Wed, 16 Nov 2016 11:56:16 -0500
From: Derek Atkins <>
To: Taylor R Campbell <>
References: <>
Date: Wed, 16 Nov 2016 11:56:16 -0500
In-Reply-To: <> (Taylor R. Campbell's message of "Mon, 14 Nov 2016 18:47:20 +0000")
Message-ID: <>
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: <>
Cc: IRTF CFRG <>, Russ Housley <>, "Scott Fluhrer (sfluhrer)" <>
Subject: Re: [Cfrg] Message Digest Algorithm Choice for CMS with Ed448
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Nov 2016 16:56:29 -0000


Taylor R Campbell <> writes:

>    Date: Mon, 14 Nov 2016 11:28:56 -0500
>    From: Derek Atkins <>
>    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 while m' is a certificate for
> Submit a CSR to a CA that you predict will issue m signed.  Now you
> have a signed certificate for

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 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, but

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

> 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?



       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant