IETF Logo Mail Archive

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

Alyssa Rowan <akr@akr.io> Mon, 07 July 2014 13:14 UTC

Return-Path: <akr@akr.io>
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 689CF1A0016 for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 06:14:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 ydFxcZWbw6lJ for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 06:14:15 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA671A000F for <tls@ietf.org>; Mon, 7 Jul 2014 06:14:14 -0700 (PDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <53B6C159.7010002@secunet.com>
References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53B6C159.7010002@secunet.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Alyssa Rowan <akr@akr.io>
Date: Mon, 07 Jul 2014 14:14:10 +0100
To: tls@ietf.org
Message-ID: <3ba0acce-d784-423b-9d6f-fccda1f183aa@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0zExTZPOwq4AfT3faIcblbIKuoY
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 13:14:17 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Well, yes - combined with an unusual ladder choice (which one might choose for constant-time, albeit not the best choice now) and a critical but easily-overlooked omission.

I appreciate there's not much we can do about implementers screwing up badly - but if we do have two primitives of about equal value and one fails catastrophically to a simple mistake that another does not, then as a matter of defence in depth, I'd generally prefer the more resilient one?

So it is with Brainpool: its twist security is poof (by pure chance) so such a mistake would be more hazardous than is typical. How likely that mistake would be is another matter, and I accept your point there that it'd be a rare decision and hopefully would be noticed in any review.

I still don't think Brainpool's fast enough to drive adoption, next to competition like 25519 and the Microsoft curves.


On 4 July 2014 15:59:37 BST, Johannes Merkle <johannes.merkle@secunet.com> wrote:

>> 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%?

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJTup0iGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t68NkP/0qjbLVNew9lCT1tUGTvsPvUsJS/WqY8JWsMfQTQJQR0mpgICIwJ
/QQ3Ocawx0Ume/WyEVo8uKOAhI/svhLEpHulQMxnq0C/RJZQXFLjRxd9E9w2jayZ
ZbU/BKw3BWdRG1oWJx6SvTNdYlcsvqhuIPbUXodG/ALrboVKDqMymfo6qSmk7kdV
T9v+jYqpST40Vkn3oqjGwn1nA6rqOAe2p9ouIWvaiC8hVu1R9VW5utHSSfFeBIFY
Uh9rLnaNoUh9UK4JUCWguql7qRWwjCwy1ZAfzPQ3Iy9pVS8oWJfQ2WQfwcLo5OSr
iilV2D1Wrk6w7C3F1LH4dsj2bTmEm2ccXTy3jVWq3AUXqlWbxOHIFtsI2V853VFR
qTvwcKb6K2ITqrbxCnSdBwhxu0GN2nxeekB8wa26xXuyfKd9JR3YzPnB/LCIOfS8
x4PBmm5/c/9uvif9x4+rGY6xRiu1uAQOfKgwr4QzzOKLe7km8pQ98gyoiqqrl9CJ
czld1JooEi8Vb3+MbGfFTmpB9KjCLsCzjdXiBylSy+k0pelVPF3em22e2aOS7uxI
qwi+/vmO9aNVdYdU/0pQ3GTayGouci7is+JTm4qpt2MQSLQfI7N4xzeAIQuTiKXv
FIn+5c9gLVsZQTAbR4VPoJC20SlQ+eb4pYOLnfA17xRcZTO+6uAAgh1n
=l0jv
-----END PGP SIGNATURE-----

v2.23.0 | Report a Bug | By Email