IETF Logo Mail Archive

Re: [TLS] Using Brainpool curves in TLS

Tom Ritter <tom@ritter.vg> Wed, 16 October 2013 13:33 UTC

Return-Path: <tom@ritter.vg>
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 8CF3E11E81D1 for <tls@ietfa.amsl.com>; Wed, 16 Oct 2013 06:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ej6mZkiAUVGb for <tls@ietfa.amsl.com>; Wed, 16 Oct 2013 06:33:17 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B583111E81D3 for <tls@ietf.org>; Wed, 16 Oct 2013 06:33:15 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id u16so1220612iet.7 for <tls@ietf.org>; Wed, 16 Oct 2013 06:33:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iZzkzglO90lbDwBzkKOgQvc5i4umiB6XE27BrI6hfoQ=; b=bagPFbipcPAtPiTCioA2qyMAHZCWfSNy/A3vNZIcPnHuuKSGkag+q+aRMP7a7ZLBBj rencdkDhRRW5+2FqwzvDq5xuTkflzmMAUAGRlJ1SlAt8KcU9D2JrodHpWJ2z0FWKOcmP fHsW7JBXCAGAbI9L26kX3sX6/LQxSWadpt0Fc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iZzkzglO90lbDwBzkKOgQvc5i4umiB6XE27BrI6hfoQ=; b=dnmDBP+aGKQeXKB2dn0iWHmRzsUP6bJTT+Hgj6HJWnX0zkYFZzpRFEICTPj8i6oDYj g8TAHMFNy/oT+6zRIpF49Ll+cET/N0dH87AW0JE+lLqhT1o+1yfGH8wFt6wVyACvHeFr H0XYk6EnMtpFmJoSgTtqmg+aC5RCzy/Iy7EDwTwnKgHa8XkPPDg/Fu5G2KiI6+NQnKvT +JZaDqExk0vI5a7jJNwPXe4cuzKeV0ZVjccnyxGjKpBEAQelJ0qhpI5gjF95owo2V8zE iGbQPefcTSzLExIW4cQyOjeV2uXJ4XNtTW2TXEp49jKR9jnqCLzLgV47qbF92+dsn35u AWpw==
X-Gm-Message-State: ALoCoQkhNSEcw+2fkDiyK8i0xqjo7xN+SMwyJ9Kcu8X2CN6jTkA4iR7pkcxFTLUK7JIk8knXDdac
X-Received: by 10.42.148.138 with SMTP id r10mr451386icv.80.1381930394444; Wed, 16 Oct 2013 06:33:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.225.15 with HTTP; Wed, 16 Oct 2013 06:32:53 -0700 (PDT)
In-Reply-To: <525E3E6B.1020604@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>
From: Tom Ritter <tom@ritter.vg>
Date: Wed, 16 Oct 2013 09:32:53 -0400
Message-ID: <CA+cU71=ws7Uh6OuJhMdU521Uvm1zj=agb3HPNZudpX1R6v7mXA@mail.gmail.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
Content-Type: text/plain; charset="ISO-8859-1"
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 13:33:18 -0000

On 16 October 2013 03:21, 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?"

http://safecurves.cr.yp.to/rigid.html

I'm not sure I agree with them fully, but I also don't have very much
context. (My thoughts when reading that is "Why sqrt(2) and sqrt(3)
instead of pi and e - what makes those constants more trustworthy?")

-tom

v2.23.0 | Report a Bug | By Email