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

"Jim Schaad" <> Wed, 03 September 2014 23:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5B5161A06B8 for <>; Wed, 3 Sep 2014 16:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nzeFl-Wf36Uc for <>; Wed, 3 Sep 2014 16:23:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36F331A6F4D for <>; Wed, 3 Sep 2014 16:23:01 -0700 (PDT)
Received: from Philemon ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 30D6A2CA36; Wed, 3 Sep 2014 16:23:00 -0700 (PDT)
From: Jim Schaad <>
To: "'Paterson, Kenny'" <>, 'Tanja Lange' <>, 'Brian LaMacchia' <>
References: <> <> <> <> <>
In-Reply-To: <>
Date: Wed, 03 Sep 2014 16:20:33 -0700
Message-ID: <041501cfc7cd$acefbf10$06cf3d30$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQG+mca7qKXwOMveQunQ/NPG1Q02DAHuAUSVAmcj9VoCDu1vXQIRIdM7m8691fA=
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 23:23:03 -0000

-----Original Message-----
From: Cfrg [] On Behalf Of Paterson, Kenny
Sent: Wednesday, September 03, 2014 12:13 PM
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

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.

[JLS] I would hope that it does not invalidate all of the proofs or the
static-ephemeral and static-static key exchange protocols that are used by
S/MIME and other off-line protocols have a real problem.


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

Cfrg mailing list