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
- Re: [Curdle] Review of draft-ietf-curdle-cms-edds… Jim Schaad
- Re: [Curdle] Review of draft-ietf-curdle-cms-edds… Russ Housley
- Re: [Curdle] Review of draft-ietf-curdle-cms-edds… Ilari Liusvaara
- Re: [Curdle] Review of draft-ietf-curdle-cms-edds… Jim Schaad
- Re: [Curdle] Review of draft-ietf-curdle-cms-edds… Russ Housley
- [Curdle] Review of draft-ietf-curdle-cms-eddsa-si… Jim Schaad