Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Andrey Jivsov <crypto@brainhub.org> Fri, 04 July 2014 21:09 UTC

Return-Path: <crypto@brainhub.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FF71A049F for <tls@ietfa.amsl.com>; Fri, 4 Jul 2014 14:09:15 -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 rHK-jnNjLGfa for <tls@ietfa.amsl.com>; Fri, 4 Jul 2014 14:09:13 -0700 (PDT)
Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id BC51F1A0463 for <tls@ietf.org>; Fri, 4 Jul 2014 14:09:13 -0700 (PDT)
Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta09.emeryville.ca.mail.comcast.net with comcast id NM2D1o0021Y3wxoA9M9DKc; Fri, 04 Jul 2014 21:09:13 +0000
Received: from [192.168.1.145] ([71.202.164.227]) by omta15.emeryville.ca.mail.comcast.net with comcast id NM9B1o00M4uhcbK8bM9CkQ; Fri, 04 Jul 2014 21:09:12 +0000
Message-ID: <53B717F7.9010109@brainhub.org>
Date: Fri, 04 Jul 2014 14:09:11 -0700
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tls@ietf.org
References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53B6C159.7010002@secunet.com> <CACsn0cnYk+MoGfGnH=cad0_sSw4WCdKehVTMBO1b4EO---PC6A@mail.gmail.com>
In-Reply-To: <CACsn0cnYk+MoGfGnH=cad0_sSw4WCdKehVTMBO1b4EO---PC6A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404508153; bh=oEmXb6v3J1awECbwtBFsJKQ2CPRexGsDyIM95+DVfi4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qROWYh0CDON+NpzvcbQHEklIUz1vNs0MXJTHBbvje7WzgRZ6IouqE93SQL9xs39uU Yq9ns+iVU/V1K7f2mZZ2FZ24T1APUO8uQrgBGlqa8K+BNsZAlMKJLpOcsFTt1tepDk 2DaVJxys+Me0OLL2pIo16TaNAJrKL5ONov8/bn+geww4h/Vaq6Bm12kJlQ2DjBB6nM moNjqdC2Pi79dFoO35jBAUGEi2hIfNCoU7FcNCfm48w/zc742Nu6pM7P7TSoOtPcun WDVX2eMJF9VTTNmfnPfxnlv78Qp9ZGEqG97mqCLiJ7YQi/mpCm65pQc18tyUwHyWCn XoLRXN9umvGoA==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pUiXT8pZ7aLBG997jUIuLEz2k9Y
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jul 2014 21:09:15 -0000

On 07/04/2014 08:15 AM, Watson Ladd wrote:
> On Fri, Jul 4, 2014 at 7:59 AM, Johannes Merkle
> <johannes.merkle@secunet.com> wrote:
>> Alyssa Rowan wrote on 27.06.2014 08:46:
>>> Brainpool has already generated a set of 'random' primes, but random primes are extremely slow to implement - and
>>> in the case of Brainpool, the 256-bit curve has extremely unfortunate lack of twist security, so any implementation
>>> that tries to skip validation is in really big trouble.
>> Why should anyone try to skip validation? In order to improve performance by less than 1%?
> Implementations frequently expose an API where validation is separate
> from group operations, and people
> just forget to make the call sometimes.

However, point validation, or validation of an element in a DH group 
(http://tools.ietf.org/html/rfc6989#section-2.2) is a common requirement 
for a crypto implementation. FIPS 140-2 crypto module algorithm 
validation includes point validation testing 
(http://csrc.nist.gov/groups/STM/cavp/documents/dss2/ecdsa2vs.pdf 
requires tests from Section A.4.2 of ANSI X9.62)

An implementation that doesn't do required EC point checks may have 
other flaws at higher levels. Replacing a low-level crypto primitive 
with a stronger one does not necessarily make the entire stack secure. 
Some may argue that this obscures the results of a security audit.

In reality all we are talking about is plugging (x,y) in the curve 
equation and checking that the two sides match. As was pointed out, when 
compression is used, this check is "forced".

> Furthermore, with anything other than a compressed format it's not
> just twist security, but any security that failure of point validation
> harms.
> I send point on a curve with smooth order, and extract the key. I send
> point on curve with small order, and dictate the key, etc.

It would be good to list what does twist security mean for TLS. 
http://safecurves.cr.yp.to/twist.html references the paper that uses an 
ElGamal decryption oracle. The attack will reveal the decryption scalar.

How does this translate to TLS? I assume we are talking about ECDH only.

Regarding dictating the key, it seems that a (corrupt) peer can always 
limit his private key to a small value and thus dictate the shared 
secret to be close to another peer's public key.

>
> Twist security matters for Joyce-Briers ladders only, as far as I know
> on Weierstrass curves. Other formulas use the y coordinates.



>
> Sincerely,
> Watson Ladd
>>
>> --
>> Johannes
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>