Re: [TLS] Using Brainpool curves in TLS

Nico Williams <> Thu, 17 October 2013 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2EB621F9CA4 for <>; Thu, 17 Oct 2013 08:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.981
X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F8Bz2LgL+gfG for <>; Thu, 17 Oct 2013 08:55:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 33ADA11E827E for <>; Thu, 17 Oct 2013 08:55:13 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id C91DF200B99A8 for <>; Thu, 17 Oct 2013 08:55:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=9P27bP4ab2JoyRRn5KsA TSOXIo0=; b=i86EgFaF3WVSqHJPsIxp2l2Y2SjVQO5h3yb1+dBZRuod7Qqv7cLT kwrKpzyWVIsTXkROjHWZUnOGMVjVKwh/3CL4DpmgfssRQiZ/o7h9Eb3WDGVXhOn9 ZmWfT/rwZq25XvtkyZftB2r8t+PV0BZnLQr97tapBlgei/CMOYfEEwc=
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 69F25200B99A4 for <>; Thu, 17 Oct 2013 08:55:12 -0700 (PDT)
Received: by with SMTP id cb5so8648936wib.13 for <>; Thu, 17 Oct 2013 08:55:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckZz12LhkjD1/iGAkafoUyH9A2a2+5UFsKk7dPQMcxs=; b=Z2Re5Um93Ma0snY60DcE4MnTlrG7xJDD2by4+ocrmdFubjeW8ragBWGuqleGaMfB4v AgEGOIqjxOCIqeliRje5K4Y1t8cikpucN/ymc73rFzhOwtddeMV7Z7J8pAajOb0iKILk la78BFzVOzP00xWVl9sTEhGwZvsEExoxk4VEEB0927o/ve/k+LEJlhC1j9Rsr7IA6Gmd LAA8sozwx4pflmWpEVq3+eo+g4tyY1076SoyAefmfOAndnB2TgpuGlz7ocstL2yRt0Gi 3xDJjNu7pKizX+IUiVOUg6s6g4OUKKLoCvT7nrPXyuDav+ey5KdI4wz8dhGyVTmkGtyI jfTg==
MIME-Version: 1.0
X-Received: by with SMTP id bp4mr7817634wjc.7.1382025310419; Thu, 17 Oct 2013 08:55:10 -0700 (PDT)
Received: by with HTTP; Thu, 17 Oct 2013 08:55:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <01b901cec9a0$004e12b0$00ea3810$> <> <> <> <> <> <> <> <>
Date: Thu, 17 Oct 2013 10:55:10 -0500
Message-ID: <>
From: Nico Williams <>
To: Johannes Merkle <>
Content-Type: text/plain; charset=UTF-8
Cc: Patrick Pelletier <>, "" <>
Subject: Re: [TLS] Using Brainpool curves in TLS
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Oct 2013 15:55:53 -0000

On Thu, Oct 17, 2013 at 3:59 AM, Johannes Merkle
<> wrote:
>> But the SafeCurves site doesn't focus only on construction rigidity,
>> and it doesn't discount Brainpool on account of rigidity in its
>> construction.  SafeCurves also covers other issues.  SafeCurves
>> declares Brainpool curves not safe according to the following
>> criteria:
>>  - feasibility of efficient constant-time implementation
>>  - twist security
> These properties are clearly beneficial to secure implementations against side-channels and active attacks. But you can
> still achieve this resistance with other curves. The approach of Brainpool was different; we gave clear hints to the
> necessity of implementation security but left the details completely to the implementors.

I would say that providing hints as to how to implement in constant
time >> providing hints that implementations should be constant-time.
Everyone knows the latter.  Not everyone knows how to achieve that.

>>    IIUC this means that when using non-twist secure curves one has to
>> validate that peers' public keys are on the curve being used, which in
>> turn would require exchanging not just public keys but also Schnorr
>> signatures (and, of course, verifying those signatures before using
>> peers' public keys for any other purpose).
> Although I am familiar with Schnorr signatures, I don't understand how they should be used for point validation.
> Typically, you need to check that the public key satisfies the curve equation. For IKE, there was an RFC published on
> how to do this during key agreement.
> If you receive a compressed key, it suffices to uncompress the key; if successful, the resulting point is on the curve.

Yeah, that was a thinko; please excuse me.  Validating that the point
is on the curve was the point.  The fact that some curve has twist
security means that for DH there's no need to validate that public
keys are points on the curve -- i.e., all other things being equal,
such a curve is faster than a curve that doesn't have this feature.
Faster is important.