Re: [TLS] Using Brainpool curves in TLS

Watson Ladd <watsonbladd@gmail.com> Wed, 16 October 2013 15:22 UTC

Return-Path: <watsonbladd@gmail.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 0783B21F9343 for <tls@ietfa.amsl.com>; Wed, 16 Oct 2013 08:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 5hfj6Xd-CuC3 for <tls@ietfa.amsl.com>; Wed, 16 Oct 2013 08:22:12 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6421F9CAF for <tls@ietf.org>; Wed, 16 Oct 2013 08:21:34 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id u56so865230wes.5 for <tls@ietf.org>; Wed, 16 Oct 2013 08:21:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rKlUtzLYy/OMbfqvqR6SwAG1cDvI+G153q1y13zAWvI=; b=R8ARzV2lA0WqhJjYzU6JuddhcRt5lZWLudrybN1/zyb6wWhjyiyNwfxrXIzI73jfVs WQtPpOPQ+iWNS/ydKZfbUYTmTHLIIvK7HiytrzwseJpB0YOfsfXSiSFggyzPtHL/A17T +y+q5blYsY9N5MmEpfC2PPLPLvYTNDA0jXCHGRvKLNtH82+D0QK94BJav8xaOjDZEGQH 9mld0RY2IHhE4V5Kdc91pD1ZzrSwbWKW75xOZPvHtlHno+yezDmOUiVNZm0XDMNHXxoa gA07dMGUiHYYQlWY83//+/JjAN7+idx4dQJhzph1uuqKcaxe0jtyFeHtAaL6r/q8ShlO Iphw==
MIME-Version: 1.0
X-Received: by 10.194.172.103 with SMTP id bb7mr1095480wjc.69.1381936893322; Wed, 16 Oct 2013 08:21:33 -0700 (PDT)
Received: by 10.194.242.131 with HTTP; Wed, 16 Oct 2013 08:21:33 -0700 (PDT)
In-Reply-To: <525EAC5D.7080105@secunet.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>
Date: Wed, 16 Oct 2013 08:21:33 -0700
Message-ID: <CACsn0cmWpj1ax+S+wTVvVU09SC_z50X=yfhDDgaq1M0AQD2jOw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
Content-Type: text/plain; charset=UTF-8
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:22:13 -0000

On Wed, Oct 16, 2013 at 8:10 AM, Johannes Merkle
<johannes.merkle@secunet.com>; wrote:
>>>> 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.
Curve25519 picks the smallest value of A that meets the parameters.
Once the prime, shape, and all restrictions are selected, the result
is deterministic. Brainpool is close enough that I would say "quite
rigid" as opposed to "deterministic construction". Basically, the
length of a PARI script to generate the curve should be short.
>
> Johannes
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin