Re: [TLS] Using Brainpool curves in TLS

Johannes Merkle <johannes.merkle@secunet.com> Thu, 17 October 2013 09:00 UTC

Return-Path: <Johannes.Merkle@secunet.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E3511E810F for <tls@ietfa.amsl.com>; Thu, 17 Oct 2013 02:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Level:
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YlbRQ-VP8py for <tls@ietfa.amsl.com>; Thu, 17 Oct 2013 02:00:04 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2CB11E8171 for <tls@ietf.org>; Thu, 17 Oct 2013 02:00:02 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 15E811A0076; Thu, 17 Oct 2013 11:00:01 +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 SAwyoEVIg8wL; Thu, 17 Oct 2013 10:59:59 +0200 (CEST)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 878321A0071; Thu, 17 Oct 2013 10:59:59 +0200 (CEST)
Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Oct 2013 11:00:00 +0200
Message-ID: <525FA70F.8030208@secunet.com>
Date: Thu, 17 Oct 2013 10:59:59 +0200
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <CACsn0ckOnrQTOLdUo9gT8hbTx4cEqX9CP6=BRFYtpV1CpT7HXQ@mail.gmail.com> <525E3E6B.1020604@secunet.com> <CA+cU71=ws7Uh6OuJhMdU521Uvm1zj=agb3HPNZudpX1R6v7mXA@mail.gmail.com> <525EAC5D.7080105@secunet.com> <CACsn0cmWpj1ax+S+wTVvVU09SC_z50X=yfhDDgaq1M0AQD2jOw@mail.gmail.com> <525EB695.9070607@secunet.com> <CAK3OfOhhxPPFTE9He+vf3BsJL4qiRgty6T9TgO2QXz7n=kbpnA@mail.gmail.com>
In-Reply-To: <CAK3OfOhhxPPFTE9He+vf3BsJL4qiRgty6T9TgO2QXz7n=kbpnA@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Oct 2013 09:00:00.0279 (UTC) FILETIME=[429FFA70:01CECB17]
Cc: Patrick Pelletier <code@funwithsoftware.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Using Brainpool curves in TLS
X-BeenThere: tls@ietf.org
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." <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: Thu, 17 Oct 2013 09:00:08 -0000

> 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
>    http://safecurves.cr.yp.to/ladder.html
> 
>  - twist security
>    http://safecurves.cr.yp.to/twist.html

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.

> 
>    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.

Johannes