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

Nico Williams <> Tue, 02 September 2014 23:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BED0F1A8874 for <>; Tue, 2 Sep 2014 16:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id olQoOR0wrbkR for <>; Tue, 2 Sep 2014 16:00:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1B9801A885F for <>; Tue, 2 Sep 2014 16:00:02 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id D3A2E2F4059 for <>; Tue, 2 Sep 2014 15:59:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=k/pInKTFIAEurNPU9yuU xyaj5vk=; b=oZkYFQb4ZqfQvVggbe0BgYjip2wfbO1eSwJQK86L+xLTflljUCmO cEVid2NLG9ZqEiGHMobiy4hhYoO4i74fWkwU1/2vX5/8GaIPryhcFEGk2NtDMagt 2qzlDIpxqi4XP+8MiagdbJ5aLWCgmqefP/8y5EYISORQoD9D+3rV7qE=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 7D38A2F4057 for <>; Tue, 2 Sep 2014 15:59:59 -0700 (PDT)
Received: by with SMTP id k48so7676467wev.34 for <>; Tue, 02 Sep 2014 15:59:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id md15mr30683294wic.3.1409698797968; Tue, 02 Sep 2014 15:59:57 -0700 (PDT)
Received: by with HTTP; Tue, 2 Sep 2014 15:59:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 02 Sep 2014 17:59:57 -0500
Message-ID: <>
From: Nico Williams <>
To: Andrey Jivsov <>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [Cfrg] On the use of Montgomery form curves for key agreement
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Sep 2014 23:00:05 -0000

On Tue, Sep 2, 2014 at 4:58 PM, Andrey Jivsov <> wrote:
> On 09/02/2014 02:47 PM, Stephen Farrell wrote:
>> 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.

+1.  We generally strive for key hygiene.  We'd not use a key for
different purposes.

What is the use of using the same key for DH and signatures in the
same protocol?  I can only think of a round-trip optimization, but
what I have in mind is very handwavy and not likely to be a win
(partly because it means losing PFS).

> 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.

Can you give some more details of what this would mean protocol-wise?

> 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.

Yes, I could see this.  Though key bundles have been around for long
enough (and in widespread enough use) that it doesn't seem likely to
matter much.

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

A self-signed DH cert.  OK, this one makes some sense, but if the
price is losing PFS or paying extra CPU cycles if you want PFS, then
it seems not worthwhile.

On the other hand, if using the same key for DH and signatures is
worthwhile, then it seems likely that point form conversion won't be a
big deal.  No?

> 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

Yes, this is a clear win.  But again, any point conversion penalty
seems minor for such a protocol.