`, "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."
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 16 Oct 2013 15:22:13 -0000
On Wed, Oct 16, 2013 at 8:10 AM, Johannes Merkle
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