Re: [Cfrg] On the use of Montgomery form curves for key agreement

Andrey Jivsov <crypto@brainhub.org> Tue, 02 September 2014 21:58 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 7B5761A0724 for <cfrg@ietfa.amsl.com>; Tue, 2 Sep 2014 14:58:38 -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, 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 7eULIOMQK-W8 for <cfrg@ietfa.amsl.com>; Tue, 2 Sep 2014 14:58:37 -0700 (PDT)
Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 47AC31A071F for <cfrg@irtf.org>; Tue, 2 Sep 2014 14:58:37 -0700 (PDT)
Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta08.emeryville.ca.mail.comcast.net with comcast id mE1h1o0031u4NiLA8Myd3j; Tue, 02 Sep 2014 21:58:37 +0000
Received: from [IPv6:::1] ([71.202.164.227]) by omta21.emeryville.ca.mail.comcast.net with comcast id mMyb1o00f4uhcbK8hMyc82; Tue, 02 Sep 2014 21:58:36 +0000
Message-ID: <54063D8B.7020302@brainhub.org>
Date: Tue, 02 Sep 2014 14:58:35 -0700
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, cfrg@irtf.org
References: <e16ac4926a934565a65456058e50b68e@BL2PR03MB242.namprd03.prod.outlook.com> <CALCETrUby2o5O3=tMkv20JTVkahSo5Wan4oSCPOspRnXhFCg+g@mail.gmail.com> <b53e2c5417d247199f4496e0c0d5c29c@BL2PR03MB242.namprd03.prod.outlook.com> <CACsn0cktxTyPpeaqKU-oL+DiP4Fu0risHB1Wx8-by+94s30h=g@mail.gmail.com> <CA+Vbu7yMvyPzRAGrtVH38mzaYy3XQ1wswEUQisqbwpT10JfQVg@mail.gmail.com> <54058021.9040801@cs.tcd.ie> <CACsn0c=XV4bQSa7Oh3=s+JvFpJdT3Lm16wQHRG2ACEjxuU-dvg@mail.gmail.com> <5405E343.7010302@cs.tcd.ie> <5406387E.4060507@brainhub.org> <54063AEA.7060903@cs.tcd.ie>
In-Reply-To: <54063AEA.7060903@cs.tcd.ie>
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=1409695117; bh=OLBkD7sv3vXOlmHGaB1trC6EAvPpkiIBzyK3nWTN5ik=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QZPpJTH8GkOqSrIZUrhujq6bhmRiyfKZMzrsPBqeTE1nSKkzltGbFsrc907dFes3I usBMR77/NA0EXf+qRYx1el/MVQLzLXmJRqKtGAoDY5+elnVu/DFnZB2cDuZrQwnSc9 vTztqzZeXZIG50NZU62YfEq65Jg4gM9UQD44ttOnLNLLnpKSw/a0aVOD1oE/F5pgvP GEs6XSpHrTHpfz7Ajz0GOaMq9B2ivARzdcULlpwC1ApnEFVw/76QapP63qkhvFqlvC ksaj7WP/wm1gsej6eLW4LmNhTjtuUGlQGvKJxDjY7gPwCj45Z5rFN51nLghymnA1HU jZ84II97hc6XA==
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/XUYml7LZFBrHxR5TUr_OllNuRks
Subject: Re: [Cfrg] On the use of Montgomery form curves for key agreement
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, 02 Sep 2014 21:58:38 -0000

On 09/02/2014 02:47 PM, Stephen Farrell wrote:
> Hiya,
>
> On 02/09/14 22:37, Andrey Jivsov wrote:
>> 10% penalty in dual-key uses
> I'm not clear what you mean by this, in terms of what protocol
> it would affect.
>
> Can you give me an example of such an IETF protocol? Without
> having thought much about it, I think there are always different
> codepoints allocated for DH and signatures, and I doubt we'd
> want the same private values shared anyway, so I'm not sure
> if that's a real or a theoretical issue.
A few examples of dual-key use and a bit braader question of whether 
would want to add points as oppose to only do scalar multiplication.

Some TLS server side fixed-base optimization will benefit from point 
addition.

While OpenPGP RFC 4880 has a concept of a "bundle of keys" things are 
easier when the top key can have both encryption and signing capability. 
There are products that add X.509 certs to PGP keys.

Signing a certificate request for a DH key to prove key possession.

Protocols for applications with space-saving requirements : keys on URLs 
or e-mail aliases, pre-generate keys "for everybody" to represent 
identities. Keys that are handled by humans (e.g. typed in base32 
encoding), etc