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

Watson Ladd <watsonbladd@gmail.com> Wed, 16 November 2016 17:18 UTC

Return-Path: <watsonbladd@gmail.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 4E69B129493 for <cfrg@ietfa.amsl.com>; Wed, 16 Nov 2016 09:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gNnmY2HjXe4V for <cfrg@ietfa.amsl.com>; Wed, 16 Nov 2016 09:18:49 -0800 (PST)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CA212941E for <cfrg@irtf.org>; Wed, 16 Nov 2016 09:18:48 -0800 (PST)
Received: by mail-vk0-x22d.google.com with SMTP id p9so120249448vkd.3 for <cfrg@irtf.org>; Wed, 16 Nov 2016 09:18:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qV0HE+RKWTvyJV91Oo7hFT1LJMp1gXdfGn2aetS7srQ=; b=wj9Aopj5DouhQoXbV+UlCCvBkNlwKg+SQBZsUo3US0+HvCKfb5h67BYQcoBjMx359V Ur4DtJotRH6EM3RKqODqg3IdoN8gQdRWAIhQHh5CtJjJZuXH1PFRVTFPIf0s0YBvjNhI WS5YVuJIW/nFKUhOUMzBu2oVyfcz36fpuhr7UxHcBzSJw7VdcXtec3qU97owhaPSc3/9 zpnIXeqVUiEmoLlz44QlFIu67oD4DjWucWC4OFNQ54BXjYlV4B6HYZPjSflUVZxiy+wq 9nEzubQYyAoM4DEqcB0xMBlzRqMHfZvkBKkUv6jZLIiQa4zGiBt9HRGvp7ae6ZI11ehM 0BMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qV0HE+RKWTvyJV91Oo7hFT1LJMp1gXdfGn2aetS7srQ=; b=JOYWX+73FSMpmBGmdmzyDYFlUb5f89ucL1XD4CQFdRRljS299Fi1g/7CSrPXjlpEX3 DQLdrDS2tN0eTMYJYpN4Dl+hLqfCgx3LhDLZIRffk4Wg/MZRAGg1ZmTRsiUqceMlJoA+ czes2Eh9cLzzTxGfdv6scP+c1zOHDGfnSltvvEngPG3tOcDuSzXctaQArEEG/+Vc6FEz 5jzRD1o/bQtkwAxnGadSWh3UKq+6vD50JN9YHYjzKVRwCAI7UFHeNd3Q6RhXOjrwdWF1 jCPJ/nUbOQxhKvZuFU1aEYWIDFBYtpeVaV8HDFsz9lFz3YXfOtAAY//08t24j9GfisX7 E3mA==
X-Gm-Message-State: ABUngvec8ndVoSdBtpa1cWpzyyqGfCluQT3lMqhTFT36ZQaMAKjS126P0f/oVh1aTketvgUIsK7vxhDTSJ7hRA==
X-Received: by 10.31.41.150 with SMTP id p144mr2165786vkp.68.1479316727783; Wed, 16 Nov 2016 09:18:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.85.18 with HTTP; Wed, 16 Nov 2016 09:18:46 -0800 (PST)
Received: by 10.176.85.18 with HTTP; Wed, 16 Nov 2016 09:18:46 -0800 (PST)
In-Reply-To: <sjm1sybs6rz.fsf@securerf.ihtfp.org>
References: <20161114184709.B803D60380@jupiter.mumble.net> <sjm1sybs6rz.fsf@securerf.ihtfp.org>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 16 Nov 2016 09:18:46 -0800
Message-ID: <CACsn0cmt+dhDCaHufB1cLNOyZu7oqVcV6jCkk_1HUwVvtbeS1w@mail.gmail.com>
To: Derek Atkins <derek@ihtfp.com>
Content-Type: multipart/alternative; boundary="001a113ef4e611e88605416e4484"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/HLWvMCt-TYMPfwteBgNaWs6uA9s>
Cc: Russ Housley <housley@vigilsec.com>, cfrg@irtf.org, "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 17:18:51 -0000

On Nov 16, 2016 8:56 AM, "Derek Atkins" <derek@ihtfp.com> wrote:
>
> 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.

Yours are nonstandard.

>
> > (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)

It is not actually so. This would violate EUF-CMA.

>
> [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
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg