Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03

Russ Housley <housley@vigilsec.com> Mon, 10 April 2017 19:31 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27F6129AD2 for <curdle@ietfa.amsl.com>; Mon, 10 Apr 2017 12:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 dmIfeaAjdunU for <curdle@ietfa.amsl.com>; Mon, 10 Apr 2017 12:31:57 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8361C129AC4 for <curdle@ietf.org>; Mon, 10 Apr 2017 12:31:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E82D130044A for <curdle@ietf.org>; Mon, 10 Apr 2017 15:31:51 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KhUcfFmug865 for <curdle@ietf.org>; Mon, 10 Apr 2017 15:31:50 -0400 (EDT)
Received: from new-host-2.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 35E48300239; Mon, 10 Apr 2017 15:31:50 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20170410192123.GA7092@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Mon, 10 Apr 2017 15:31:49 -0400
Cc: Jim Schaad <ietf@augustcellars.com>, curdle <curdle@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <183765B4-285D-4920-AF3E-80B0F661CEDF@vigilsec.com>
References: <059e01d2a8a4$270b2370$75216a50$@augustcellars.com> <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com> <20170410192123.GA7092@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/ozTj6TSO5q9wadpVwTihgWEEVEM>
Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Apr 2017 19:32:00 -0000

Ilari:

>> 
>>> Section 3.1 - I would like to have a brief discussion on the integer value
>>> that is being used with the id-shake256-len OID when it is being used as a
>>> digest algorithm.  The value of 512 means that the signature security is
>>> going to be the same as is currently setup for Ed25519.  To have the same
>>> dynamic as Ed25519 does, this should be 448*2 so that after birthday attacks
>>> the same size of value would be provided.
>> 
>> RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used.  Reading
>> a bit more carefully, I see that the output is 114 octets or 912 bits.
> 
> Nitpick: Only true of no-prehash versions. The prehash itself uses
> SHAKE256 with 512-bit input.
> 
>> I suggest that we align with these values.  That is:
>> 
>>   When signing with Ed448, the message digest
>>   algorithm MUST be SHAKE256 [FIPS202] with a 912-bit output value.
>> 
>> and
>> 
>>   When using the id-shake256-len algorithm identifier, the parameters
>>   MUST be present, and the parameter MUST contain 912, encoded as a
>>   positive integer value.
> 
> The hash algorithm is internal detail of EdDSA, unless you are talking
> about doing prehashing at "application" level (which certainly a valid
> approach).
> 
> On security of using just 512-bit hash there, SHAKE256 does not promise
> resistance above 2^256 for any attack, which it reaches at 512-bit output
> (collision resistance being the limiting factor). And the security
> level of the curve certainly isn't above 2^256.
> 
> So 512-bit hash should be entierely adequate for application-level
> prehash (just don't use SHA3-512, it is hilariously slow).

CMS supports signatures with and without signed attributes.  In most cases, signed attributes are present.  When signed attributes are present, the message-digest attribute MUST be one of the attributes.  It was signed to work like this:

    IF (signed attributes are absent)
    THEN md = Hash(content)
    ELSE message-digest attribute = Hash(content);
         md = Hash(DER(SignedAttributes))

    Sign(md)

So, I think you are saying that a 512-bit output was sufficient, which is what was present in the earlier text:

   When using the id-shake256-len algorithm identifier, the parameters
   MUST be present, and the parameter MUST contain 512, encoded as a
   positive integer value.

Russ