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

Olafur Gudmundsson <ogud@ogud.com> Tue, 05 May 2015 22:48 UTC

Return-Path: <ogud@ogud.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 855981B2A72 for <cfrg@ietfa.amsl.com>; Tue, 5 May 2015 15:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 EhMTnBdh1RuR for <cfrg@ietfa.amsl.com>; Tue, 5 May 2015 15:48:45 -0700 (PDT)
Received: from smtp93.iad3a.emailsrvr.com (smtp93.iad3a.emailsrvr.com [173.203.187.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2661B2A6F for <cfrg@irtf.org>; Tue, 5 May 2015 15:48:45 -0700 (PDT)
Received: from smtp28.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id ABC6E380379; Tue, 5 May 2015 18:48:44 -0400 (EDT)
Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 4880A380138; Tue, 5 May 2015 18:48:41 -0400 (EDT)
X-Sender-Id: ogud@ogud.com
Received: from [192.168.50.174] ([TEMPUNAVAIL]. [194.168.195.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 05 May 2015 22:48:44 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <87383b5ckq.fsf@latte.josefsson.org>
Date: Tue, 05 May 2015 18:48:46 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <33EFA4CC-BD3E-428C-9F07-ADBE9880B73F@ogud.com>
References: <5546032D.5070208@isode.com> <87383b5ckq.fsf@latte.josefsson.org>
To: Simon Josefsson <simon@josefsson.org>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/7DQFQXICtz7xIF-rONHmNMzarxw>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [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: Tue, 05 May 2015 22:48:47 -0000

+1  I could not have put my arguments any better than Simon did. 
#2 is the only reasonable choice at this point. 

Olafur

> On May 5, 2015, at 10:22 AM, Simon Josefsson <simon@josefsson.org> wrote:
> 
> Alexey Melnikov <alexey.melnikov@isode.com> writes:
> 
>> 1. CFRG should stick to randomised signature schemes only.
> 
> No.
> 
>> 2. CFRG should adopt deterministic signature scheme only.
> 
> At this time, yes.
> 
> There are situations where you need non-determinism in a public-key
> signature scheme to achieve certain properties.
> 
> I believe it will eventually be useful for the CFRG to recommend a
> non-deterministic signature scheme that is better than RSA/DSA/ECDSA.
> 
> As Andy said, you can have a scheme that is secure in a deterministic
> setting but still accept ranndomness to achieve a non-deterministic
> signature, for wider applicability.
> 
> However the majority of applications under consideration today (e.g.,
> PKIX, TLS, S/MIME, OpenPGP) would directly benefit from having a good
> and easy to implement deterministic signature scheme, like EdDSA.
> 
> So I believe this should be the focus for the current agenda.
> 
>> 3. De-randomisation should be an optional feature for implementers to
>> decide upon (i.e. both choices 1 and 2 allowed).
> 
> No.
> 
> /Simon
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg