IETF Logo Mail Archive

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

Jim Schaad <ietf@augustcellars.com> Mon, 10 April 2017 19:09 UTC

Return-Path: <ietf@augustcellars.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 3475E129532 for <curdle@ietfa.amsl.com>; Mon, 10 Apr 2017 12:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 f9Q5g58h9peU for <curdle@ietfa.amsl.com>; Mon, 10 Apr 2017 12:09:35 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE7B127601 for <curdle@ietf.org>; Mon, 10 Apr 2017 12:09:35 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491851370; h=from:subject:to:date:message-id; bh=WeOWg9Xh1gwBMciPRpdB2H8nklxBliWIWV9LGVLPqnM=; b=g9dRkouSasLLtUb6kaAwHq5r9qbJm+wW01FXpjYNthDtyb0Q8Rlg3L8fDz3Fy7JV56ocw/YcVtz ZjObHt4LS0Np0ZlMWNL4DJqTlW1OKLVGvt9ZOtoV0Dd7vZ679VeJwGST/2pdwc3hda5puf+yXKZY/ J4sV0wuYMi4M/OxnDYjm1aQdNSOv8D6Z/X3z0GAQeQRExUZo0NavPOEJFdOLSI/qlpOrBQu+IaGo8 a5cagRn9xh5Tq3MXynuYpRmOqunXr5YhNWjWo2imoYcNrK1aDNR5sq8o4WUWkef+AnacbkPmiLCpS 4naHS5UFuNJgtEyL2o/dRbSb5GCaKfm9/YBQ==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 12:09:30 -0700
Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 12:09:28 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>
CC: 'curdle' <curdle@ietf.org>
References: <059e01d2a8a4$270b2370$75216a50$@augustcellars.com> <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com>
In-Reply-To: <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com>
Date: Mon, 10 Apr 2017 12:09:26 -0700
Message-ID: <003e01d2b22d$fa6f8250$ef4e86f0$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJSzE5P3lUIm/XKUSywOQEvOhZJ9AJrO/vDoKtpBIA=
X-Originating-IP: [192.168.0.98]
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/_TdNHGbmSaM_TOQM0wnWlWyq4zM>
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:09:38 -0000


> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Monday, April 10, 2017 12:00 PM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: curdle <curdle@ietf.org>
> Subject: Re: Review of draft-ietf-curdle-cms-eddsa-signatures-03
> 
> Jim:
> 
> Sorry, I flagged this message in my inbox, and then I missed it when I
made the
> update earlier today.
> 
> > 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.
> 
> 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.

Yes - this is what I wanted to do.  This is what Sean was supposed to run
past Tanya and the question was "Did the fact that it was SHAKE256 limit the
number of bits despite the added output length?"  

> 
> 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.
> 
> > Section 4 - I thing that it should also be highlighted that this is a
> > greater problem for when using the Signed-data without signed
> > attributes as the value signed is more constrained in the other case.
> 
> I suggest:
> 
> 4.  Implementation Considerations
> 
>    The EdDSA specification [EDDSA] includes the following warning.  It
>    deserves highlighting, especially when signed-data is used without
>    signed attributes and the content to be signed might be quite large:
> 
>       PureEdDSA requires two passes over the input.  Many existing APIs,
>       protocols, and environments assume digital signature algorithms
>       only need one pass over the input, and may have API or bandwidth
>       concerns supporting anything else.

This looks good.

Jim

> 
> Russ

v2.23.0 | Report a Bug | By Email