[Cfrg] Elliptic Curves - signature scheme: randomised or not (ends on May 13th)

Alexey Melnikov <alexey.melnikov@isode.com> Sun, 03 May 2015 11:14 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948E31A039C for <cfrg@ietfa.amsl.com>; Sun, 3 May 2015 04:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.69
X-Spam-Level:
X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 1xtFIqiyXiW6 for <cfrg@ietfa.amsl.com>; Sun, 3 May 2015 04:14:56 -0700 (PDT)
Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 017FC1A0A6A for <cfrg@irtf.org>; Sun, 3 May 2015 04:14:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1430651695; d=isode.com; s=selector; i=@isode.com; bh=d75n19i9el/raA5s/iUibQv0O0PYi7nfp/MYe80ueKA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cggxYjdfmnMrnZnmsrWHdL5NoHaDIO6n8amGZK4lHCYX2Jg3Wppg/pxhmqEasksWmlMkBo ENUdIZ5Bel4kFrd/wLTVupFaEJsd6F2SR9i9srmnfn4B9yOaUZlqnGFAooOjBf7UDHNjsv 5pcnLsBGZMdG1krLxcTSbzCdi/R8gL4=;
Received: from [192.168.0.5] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VUYDLgAYQUbG@waldorf.isode.com>; Sun, 3 May 2015 12:14:54 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <5546032D.5070208@isode.com>
Date: Sun, 03 May 2015 12:14:53 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
To: "cfrg@irtf.org" <cfrg@irtf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------000004060606000104040609"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/NKiP_VOxTNI6lhukz7BP1Dh5kkk>
Subject: [Cfrg] Elliptic Curves - signature scheme: randomised or not (ends on May 13th)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2015 11:14:57 -0000

CFRG chairs are starting discussion of the next topic.

The consensus view of the mailing list was that NIST compliance of our 
selected
signature scheme is not necessary, opening up the opportunity for us to
consider a rich class of signature schemes beyond ECDSA.

Most if not all signature schemes defined over elliptic curves can be
de-randomised by generating the "random" value used during signing in a
pseudorandom manner from the message to be signed. This ameliorates some
catastrophic failure modes for these schemes. The generation could involve
using a PRF such as HMAC with a key designed solely for this purpose
(resulting in an augmented private (signing) key). An alternative could be
to hash a string consisting of a concatenation of the private (signing)
key with the message to be signed. There are other possibilities too.
Several methods are described in detail in RFC 6979
(http://tools.ietf.org/html/rfc6979).

To determine the way forward, we are going to conduct a poll to determine
how we should tackle the question of de-randomisation. Please pick one 
of the
options specified below:

1. CFRG should stick to randomised signature schemes only.

2. CFRG should adopt deterministic signature scheme only.

3. De-randomisation should be an optional feature for implementers to
decide upon (i.e. both choices 1 and 2 allowed).

Please address only this specific topic of de-randomisation at this time.
Further topics will follow.