IETF Logo Mail Archive

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

Taylor R Campbell <campbell+cfrg@mumble.net> Mon, 14 November 2016 23:39 UTC

Return-Path: <campbell@mumble.net>
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 58F53128874 for <cfrg@ietfa.amsl.com>; Mon, 14 Nov 2016 15:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] 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 Q5oPdyWFSk50 for <cfrg@ietfa.amsl.com>; Mon, 14 Nov 2016 15:39:18 -0800 (PST)
Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) by ietfa.amsl.com (Postfix) with ESMTP id 770421293F9 for <cfrg@irtf.org>; Mon, 14 Nov 2016 15:39:18 -0800 (PST)
Received: by jupiter.mumble.net (Postfix, from userid 1014) id 5486660380; Mon, 14 Nov 2016 23:39:07 +0000 (UTC)
From: Taylor R Campbell <campbell+cfrg@mumble.net>
To: "Salz, Rich" <rsalz@akamai.com>
In-reply-to: <10d6e6fec75e4d6cadc11f48e54f61f4@usma1ex-dag1mb1.msg.corp.akamai.com> (rsalz@akamai.com)
Date: Mon, 14 Nov 2016 23:39:17 +0000
Sender: Taylor R Campbell <campbell@mumble.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <20161114233907.5486660380@jupiter.mumble.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/_0dArTtM42Q2R7md841hCIDq0S8>
Cc: Russ Housley <housley@vigilsec.com>, Jim Schaad <ietf@augustcellars.com>, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, IRTF CFRG <cfrg@irtf.org>
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: Mon, 14 Nov 2016 23:39:19 -0000

   Date: Mon, 14 Nov 2016 23:15:56 +0000
   From: "Salz, Rich" <rsalz@akamai.com>

   For this document, we are not defining a new signing technique, we
   are defining how to use the existing techniques with current
   crypto.  Make sense?

Not sure what you mean here.  H(r, m) is an exising technique with
current crypto -- the plethora of applications using Ed25519 out of
libsodium or whatever do exactly this, picking r = H(sk, m) where sk
is the long-term secret key.  This doesn't require extra inputs to the
signature on the part of the user -- the user still just feeds in a
long-term secret signing key sk and a message m, and gets out a
signature or signed message.

A prehash is needed only for legacy protocols that foolishly insist on
incorporating the message m only via a single fixed public hash
function H(m) of it, which renders them vulnerable to collisions in H,
or forces them to pay the additional cost of collision resistance.

v2.23.0 | Report a Bug | By Email