Re: [Cfrg] matching AES security

Brian Smith <> Thu, 31 July 2014 15:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E427D1A028B for <>; Thu, 31 Jul 2014 08:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rsLjT37qD9GY for <>; Thu, 31 Jul 2014 08:57:51 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DDDC1A00B5 for <>; Thu, 31 Jul 2014 08:57:51 -0700 (PDT)
Received: by with SMTP id a108so4219959qge.16 for <>; Thu, 31 Jul 2014 08:57:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=AwZx+w6dD+TKV8JkRC3y1IJU5YXzVM8uC9vE8eHVC6Q=; b=iWJRyf0ZUC77xog3MXkJdjPneRwyGQWvvvbTOmAd5uWrhZ5YS6JsDNpw8OKz8LgFUl CezPRd4xXoKkxP1rNck1sHWvne82bAtG0ATiTCvQFi1vv3aAUJf2csJv/wZ9ucITtLmh Ka9G8f7cPjtnGQMxt+5lLkwZiY3qSInD5ntFMkajFbum3RckmvMqjnzSvh5Up5+Mmo6v sndaQo9IVnbAAG8MyyAEtIo9TJ8R7VS9z73XdT+OvH8sw46KQaF0WzeRqSQAKGO1vmsm Ve7369F1Gi57pkm6bJFbALKJvXSkamvDuE9wJ9dnMRHn72/oxEpG+gOuIGAX+/Vt+ogZ CdEQ==
X-Gm-Message-State: ALoCoQm+kFeDctUq8C87meyJQssqy25zjcjE24kgXOwAanYgX8jLE4daLT8OQhtU1f/gRdJqyHlM
MIME-Version: 1.0
X-Received: by with SMTP id ca1mr19787327qcb.28.1406822270776; Thu, 31 Jul 2014 08:57:50 -0700 (PDT)
Received: by with HTTP; Thu, 31 Jul 2014 08:57:50 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 31 Jul 2014 08:57:50 -0700
Message-ID: <>
From: Brian Smith <>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Cfrg] matching AES security
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Jul 2014 15:57:55 -0000

On Wed, Jul 30, 2014 at 5:33 AM, D. J. Bernstein <> wrote:
> These attacks assume that the attacker sees ciphertext for, e.g., an
> all-zero block encrypted under all of the keys. Sometimes protocols
> randomize their blocks to try to stop these attacks---but putting
> complications into protocols to compensate for a cipher's deficient
> security is _not_ a smart way to design a cryptographic system.

I agree that it would be better to not need to randomize blocks to
avoid the attacks you alluded to. However, it seems like randomizing
the blocks is often easy; for example, I think it would be pretty easy
to define AES-GCM and ChaCaa20-Poly1305 cipher suites for TLS in a way
where the initial nonce is comes from the PRF and then incremented.

Don't you think it is worthwhile to do such randomization anyway,
since the randomization acts as a second line of defense against a
variety of problems? Is doing so harmful in some way?

>    * the point that it's already common practice to combine, e.g.,
>      RSA-2048 with AES-128 and sometimes even AES-256, illustrating that
>      the users' performance constraints are the biggest issue;

I agree with this. I'd also like to point out that I've yet to hear
anybody say that the P-256 curve is too slow for them to use. I've
heard others say that it would be nice to have a faster curve like
Curve25519, and I've heard people say that it is important to replace
P-256 with a curve that we trust more like Curve25519 (for some value
of "we"). Curve25519 has kind of become the default choice since it
seems to meet both the "nice to have" performance criteria and the
"must-have" security criteria for many people.

However, as a thought experiment, imagine that we had a proof that
P-256 was secure (including a proof that the mysterious constant is
not a security issue). I think a lot of the urges to replace P-256
would vanish because P-256 performance isn't that bad and almost
everybody has an implementation. That, combined with the common sense
that computations per second will increase and attacks will improve,
makes me think that it makes more sense to standardize on a curve with
roughly the same performance of P-256 but with better security,
particularly if such a curve could cover multiple security levels
(128-bit and 192-bit) so that there is less need to rely on
negotiation mechanisms in protocols to select an acceptable curve.

I think it would make a lot more sense to standardize one
~192-bit-security-level curve than to standardize one 128-bit curve
AND one 192-bit curve AND one 256-bit curve just so we can say we've
"matched" security levels. I don't think "matching" is useful for many
applications, including in particular the use of TLS in web browsers
and similar applications.

It would be interesting to hear from people who could not use P-256,
Curve41417, or other curves of around the same performance level for
*performance* reasons.