Re: [TLS] Using Brainpool curves in TLS

Johannes Merkle <johannes.merkle@secunet.com> Wed, 16 October 2013 15:10 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 5DF8221F84D9 for <tls@ietfa.amsl.com>; Wed, 16 Oct 2013 08:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.501
X-Spam-Level:
X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 nnfTXwNyr+58 for <tls@ietfa.amsl.com>; Wed, 16 Oct 2013 08:10:39 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5E13D11E82AB for <tls@ietf.org>; Wed, 16 Oct 2013 08:10:25 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2C8001A0078; Wed, 16 Oct 2013 17:10:23 +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 5f4MGwWJCBdJ; Wed, 16 Oct 2013 17:10:22 +0200 (CEST)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 08F0C1A0076; Wed, 16 Oct 2013 17:10:22 +0200 (CEST)
Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Oct 2013 17:10:21 +0200
Message-ID: <525EAC5D.7080105@secunet.com>
Date: Wed, 16 Oct 2013 17:10:21 +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: Tom Ritter <tom@ritter.vg>
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>
In-Reply-To: <CA+cU71=ws7Uh6OuJhMdU521Uvm1zj=agb3HPNZudpX1R6v7mXA@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Oct 2013 15:10:22.0236 (UTC) FILETIME=[D587C5C0:01CECA81]
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: Wed, 16 Oct 2013 15:10:44 -0000

>>> What problems does this solve? The Brainpool curves still have
>>> unverifiable construction,
>>
>> This is plain wrong. Obviously, you have not read RFC 5639. The construction of the Brainppol curves is completely
>> verifiable, only based on the fundamental constants Pi and e.
> 
> Repeating others arguments:
> 
> "Several unexplained decisions: Why SHA-1 instead of, e.g., RIPEMD-160
> or SHA-256? Why use 160 bits of hash input independently of the curve
> size? Why pi and e instead of, e.g., sqrt(2) and sqrt(3)? Why handle
> separate key sizes by more digits of pi and e instead of hash
> derivation? Why counter mode instead of, e.g., OFB? Why use
> overlapping counters for A and B (producing the repeated
> 26DC5C6CE94A4B44F330B5D9)? Why not derive separate seeds for A and B?"

The fact that the source of the seeds is explained is a huge step towards complete transparency as compared to the NIST
curves. Your arguments refer to the procedure for derivation of the parameters from the fundamental constants. There is
no canonical choice for such a procedure; the most obvious approach was to take it from ANSI X9.62, which we did.
Admittedly, we introduced a slight change: we use the first two PRNG outputs as coefficients a and b, whereas ANSI uses
the first PRNG output as r=a^3/b^2 and selects a and b arbitrarily with that relation); but this change is rather small
and quite straightforward. IMO there is really not much room left for conspiracy theories.

Anyone who is so paranoid (in the positive way which is useful for IT security professionals) to fear that a backdoor
may have been built in by tuning the parameter generation procedure should also question all design criteria for any
other curve, including Curve25519. There is always room for choices.

Johannes