Re: [Cfrg] EC - next steps to get draft-irtf-cfrg-curves done

Andrey Jivsov <crypto@brainhub.org> Tue, 10 February 2015 22:19 UTC

Return-Path: <crypto@brainhub.org>
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 0B9271A0149 for <cfrg@ietfa.amsl.com>; Tue, 10 Feb 2015 14:19:10 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 rCalS1ynUHff for <cfrg@ietfa.amsl.com>; Tue, 10 Feb 2015 14:19:08 -0800 (PST)
Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F641A0166 for <cfrg@irtf.org>; Tue, 10 Feb 2015 14:19:07 -0800 (PST)
Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-05v.sys.comcast.net with comcast id qmJ51p0025BUCh401mK7ae; Tue, 10 Feb 2015 22:19:07 +0000
Received: from [IPv6:::1] ([71.202.164.227]) by resomta-po-16v.sys.comcast.net with comcast id qmK61p00G4uhcbK01mK6Mi; Tue, 10 Feb 2015 22:19:07 +0000
Message-ID: <54DA83DA.3050209@brainhub.org>
Date: Tue, 10 Feb 2015 14:19:06 -0800
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Tony Arcieri <bascule@gmail.com>
References: <54D9E0F1.7050600@isode.com> <54DA42E1.50007@cs.tcd.ie> <CACsn0ckrsBX4zNrQznReR8MrgR6T7SGGk0=xxviK0mN5p5ec4Q@mail.gmail.com> <D10025F4.3E69B%kenny.paterson@rhul.ac.uk> <CAHOTMVKDm+o6ZwUcER8hyT7=1QyOVLmbSsYsffBWx3v-FNipTg@mail.gmail.com> <54DA8121.9030603@brainhub.org> <CAHOTMV+i=HvZrQp2NQysmo7MjPEBewf8mTD8Cf66dw3bxTZrsQ@mail.gmail.com>
In-Reply-To: <CAHOTMV+i=HvZrQp2NQysmo7MjPEBewf8mTD8Cf66dw3bxTZrsQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1423606747; bh=7aamhUA5wZSe0+Oc3GALmrV8Z1jZkF+oe0jMYIQuR8M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Diwfl38Dcz9iBU+FwhIsFykr18DTpg5FcUJwYV0stsP7Z/iDpH89AE+KuZ3arcilp MxCBdVqLeagfR1Htj5z+Kv0Cqe9pzH9ZhP5ubEKEiD7zyGltvlgkZ9FTMf7EzVvWCe xWOVySAq7zdG14wu80aTnb6jEjWm+Vrq3qKsmvzNx8YFFaDyNeVtI/7yNDJeQhgnYE +ckt2qwzkipz4MVCCFltR9yfdRJirMDc5fO90EExSyBQ6P1olOQ7tWubIItN+Fv7Sz 11KXWKqC0xRRc5T4usrve8RKDLd2CtS0c6vxQlhc/ev4x9Mo9LrY18tYJSYHde1XAx 1Z6rEkSU/ve6Q==
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/NPum8kQuab1YljDr4GMxYKYNgqA>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] EC - next steps to get draft-irtf-cfrg-curves done
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, 10 Feb 2015 22:19:10 -0000

On 02/10/2015 02:12 PM, Tony Arcieri wrote:
> On Tue, Feb 10, 2015 at 2:07 PM, Andrey Jivsov <crypto@brainhub.org 
> <mailto:crypto@brainhub.org>> wrote:
>
>     The above reads a bit odd. Often the hash function cannot be
>     perfectly matches to the curve size, thus the expansion or
>     contraction rules are defined and relied upon.
>
>     e.g. one can use SHA-256 with P-384.
>
>
> EdDSA in its current form uses hash functions in many places. One of 
> them is as a KDF for the private scalar.
>
>

OK, but I think this is fine.

SHA-256 + P-384 is expected to have 128-bit security. Likewise, it seems 
OK to allow the padding/truncation with EdDSA. It will make the 
higher-level system less flexible and harder to deploy if the hash 
algorithm (or hash algorithm size) are hardwired into the signature 
algorithm for the curve size.