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

Markulf Kohlweiss <> Thu, 04 September 2014 07:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C5D321A1F70 for <>; Thu, 4 Sep 2014 00:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nC6XyKaZHCj1 for <>; Thu, 4 Sep 2014 00:23:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 84EED1A001A for <>; Thu, 4 Sep 2014 00:23:14 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1019.16; Thu, 4 Sep 2014 07:23:12 +0000
Received: from (2a01:111:f400:7c10::184) by (2a01:111:e400:2c5d::46) with Microsoft SMTP Server (TLS) id 15.0.1019.16 via Frontend Transport; Thu, 4 Sep 2014 07:23:12 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Thu, 4 Sep 2014 07:23:12 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 4 Sep 2014 07:22:34 +0000
Received: from ([]) by ([]) with mapi id 14.16.0466.000; Thu, 4 Sep 2014 07:22:33 +0000
From: Markulf Kohlweiss <>
To: "Paterson, Kenny" <>, Tanja Lange <>, Brian LaMacchia <>
Thread-Topic: [Cfrg] On the use of Montgomery form curves for key agreement
Thread-Index: Ac/GFKdVASv0pPTeROyHvj6EvV57FQAucr0AABmnhBAAAKhnAAAe8jSAABa/d5A=
Date: Thu, 04 Sep 2014 07:22:33 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(53754006)(479174003)(189002)(199003)(24454002)(51704005)(13464003)(80022001)(81342001)(66066001)(50466002)(64706001)(20776003)(47776003)(2421001)(86146001)(2656002)(15202345003)(85306004)(93886004)(46102001)(76482001)(15975445006)(77982001)(1511001)(55846006)(77096002)(79102001)(83072002)(84676001)(92726001)(86612001)(85852003)(86362001)(69596002)(68736004)(90102001)(19580405001)(19580395003)(83322001)(6806004)(44976005)(31966008)(23756003)(92566001)(99396002)(50986999)(16796002)(81542001)(33656002)(26826002)(74502001)(95666004)(76176999)(107046002)(87936001)(97736001)(74662001)(106466001)(81156004)(4396001)(21056001)(54356999); DIR:OUT; SFP:; SCL:1; SRVR:CH1PR03MB622;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0324C2C0E2
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
Cc: "" <>, Cedric Fournet <>
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: Thu, 04 Sep 2014 07:23:17 -0000

Hi all,

Mostly in reply to Kenny's comments on provable security and miTLS. We discussed this internally and have very partial results that should be extended. 

The miTLS master-secret KEM does not distinguish between one-time use of the KEM public key, and reuse. So the main proof (of a theorem that does not model PFS) also holds for TLS-DHE in settings where server public keys are reused. On the other hand the KEM abstraction does not allow for client-side reuse of ephemeral values. In KEM terminology: Enc always uses fresh randomness.

What are you most concerned about client or server side reuse of ephemeral secrets?

How one would model PFS in such a time-based manner is fascinating. The current, again rudimentary modelling of PFS in miTLS (you have to dig in the appendix) only models signing key compromise, but not temporal ephemeral secret compromise. 


PS. I added Cedric in CC to fact check what I am saying. In these subtle issues the verification of the implementation may be more detailed than the paper crypto proof. 

-----Original Message-----
From: Paterson, Kenny [] 
Sent: 03 September 2014 20:13
To: Tanja Lange; Brian LaMacchia
Subject: Re: [Cfrg] On the use of Montgomery form curves for key agreement


On 03/09/2014 06:27, "Tanja Lange" <> wrote:

>Dear Brian,
>> Regarding the specific issue you raised concerning Microsoft¹s TLS 
>>implementation, as you will recall Tanja first mentioned this issue to 
>>me during dinner i
>I actually made this statement in public in the Q&A after my talk when 
>David McGrew asked about the ephemeral key case.

This is indeed true as the minutes should show. But it was a topic of some passionate discussion at the dinner later, IIRC.

>> As for your suggestion regarding a blanket prohibition on reuse of 
>>any ephemeral cryptographic keys across all IETF protocols, given the 
>>current environment that does indeed seem like a good idea to me.  I 
>>guess what we¹d really want to do is have CFRG issue a BCP on this 
>>point, if that¹s something the IRTF is allowed to do (I don¹t know the 
>>answer to that process question).  Perhaps CFRG can take that issue up 
>>once the curve selection process has concluded.
>What exactly do you think the security implications of key reuse are?
>Defining ephemeral in a time-based manner ist quite normal; the 
>important thing to guarantee PFS is to delete the key afterwards, not 
>whether it is used for 1 connection or 10 seconds (with potentially 0 connections).

For what it's worth, ephemeral reuse invalidates all the formal security analyses (in the provable security tradition) for key exchange protocols that I know of. It certainly invalidates those proofs that I understand for the TLS Handshake. Would be interesting if the miTLS guys could say what it means for their TLS proofs from Crypto'14.

My feeling is that this can be got around in the random oracle model for protocols that hash the DH shared value and various other components by using a suitable gap assumption or strong DH assumption. However, some care would be needed in the analysis. Coming up with a standard model proof for some specific protocol seems much harder because of the obvious "correlation" between shared DH values that different parties would end up with. Hashing with a random oracle of course destroys such relations.

There's probably a nice research paper in this for someone - if it's not already been done (indeed writing such a paper has been on my to do list for some time - since long before this thread got started).



>All the best
>	Tanja
>Cfrg mailing list