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

Johannes Merkle <johannes.merkle@secunet.com> Mon, 07 July 2014 12:49 UTC

Return-Path: <Johannes.Merkle@secunet.com>
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 60FAB1B284A for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 05:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.352
X-Spam-Level:
X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 7sxqofCejpNm for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 05:49:04 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A971B1B2845 for <tls@ietf.org>; Mon, 7 Jul 2014 05:49:04 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id BCC9F1A0091; Mon, 7 Jul 2014 14:48:58 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pXtIXdh_Odvb; Mon, 7 Jul 2014 14:48:53 +0200 (CEST)
Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 7EAC21A0066; Mon, 7 Jul 2014 14:48:53 +0200 (CEST)
Received: from [10.53.40.204] (port=50437 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1X48Lm-00028y-PF; Mon, 07 Jul 2014 14:48:54 +0200
Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 7 Jul 2014 14:48:54 +0200
Message-ID: <53BA9735.5040903@secunet.com>
Date: Mon, 7 Jul 2014 14:48:53 +0200
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>
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>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.208.1.76]
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zJbuEKfQ0de0FmCwuv3EK_0n9oc
Cc: "tls@ietf.org" <tls@ietf.org>
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: Mon, 07 Jul 2014 12:49:07 -0000

Watson Ladd wrote on 04.07.2014 17:15:

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

Exactly, and as DJB points out, the Joyce-Briers ladder "requires 19 field operations per bit, many more field
operations than standard addition chains for short Weierstrass curves" [1]. Therefore, "twist security" is irrelevant
for Weierstrass curves unless someone decides to implement the Joyce-Briers ladder despite of its inferior performance.

I was objecting to Alyssa's statement "in the case of Brainpool, the 256-bit curve has extremely unfortunate lack of
twist security", which, IMHO, grossly exaggerates the importance of twist security. Lack of "twist security" is an issue
for Weierstrass curves only in circumstances where implementors choose an unusual technique and screw up one essential
part.

[1] http://safecurves.cr.yp.to/ladder.html
-- 
Johannes