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

"Paterson, Kenny" <> Wed, 03 September 2014 19:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DF6C31A0657 for <>; Wed, 3 Sep 2014 12:13:23 -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 xw6KhZSs-KwR for <>; Wed, 3 Sep 2014 12:13:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2130E1A0704 for <>; Wed, 3 Sep 2014 12:13:19 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 3 Sep 2014 19:13:18 +0000
Received: from ([]) by ([]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 19:13:17 +0000
From: "Paterson, Kenny" <>
To: Tanja Lange <>, Brian LaMacchia <>
Thread-Topic: [Cfrg] On the use of Montgomery form curves for key agreement
Thread-Index: Ac/GFKdVASv0pPTeROyHvj6EvV57FQAucr0AABmnhBAAAKhnAAAe8jSA
Date: Wed, 03 Sep 2014 19:13:17 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 032334F434
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(479174003)(189002)(51704005)(199003)(24454002)(76176999)(21056001)(93886004)(54356999)(2421001)(99396002)(50986999)(81542001)(86362001)(81342001)(90102001)(87936001)(36756003)(92726001)(80022001)(83072002)(92566001)(66066001)(95666004)(46102001)(64706001)(4396001)(74662001)(83506001)(15202345003)(74482001)(79102001)(15975445006)(31966008)(107046002)(19580405001)(85306004)(83322001)(19580395003)(77982001)(74502001)(20776003)(1511001)(85852003)(2656002)(105586002)(106356001)(101416001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB384;; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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: Wed, 03 Sep 2014 19:13:24 -0000


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