Re: [Cfrg] matching AES security
Brian Smith <brian@briansmith.org> Thu, 31 July 2014 15:57 UTC
Return-Path: <brian@briansmith.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E427D1A028B for <cfrg@ietfa.amsl.com>; Thu, 31 Jul 2014 08:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsLjT37qD9GY for <cfrg@ietfa.amsl.com>; Thu, 31 Jul 2014 08:57:51 -0700 (PDT)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDDC1A00B5 for <cfrg@irtf.org>; Thu, 31 Jul 2014 08:57:51 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id a108so4219959qge.16 for <cfrg@irtf.org>; Thu, 31 Jul 2014 08:57:50 -0700 (PDT)
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: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 10.229.182.1 with SMTP id ca1mr19787327qcb.28.1406822270776; Thu, 31 Jul 2014 08:57:50 -0700 (PDT)
Received: by 10.224.189.200 with HTTP; Thu, 31 Jul 2014 08:57:50 -0700 (PDT)
In-Reply-To: <20140730123336.29011.qmail@cr.yp.to>
References: <20140730123336.29011.qmail@cr.yp.to>
Date: Thu, 31 Jul 2014 08:57:50 -0700
Message-ID: <CAFewVt4jNUVK5PBDUoMJ0y4YzZ1e5okztV3qpT6J5aK0KmC0wg@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: cfrg@irtf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/0wi7Wi26lFuH0tOijBcg7X269x0
Subject: Re: [Cfrg] matching AES security
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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 <djb@cr.yp.to> 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. Cheers, Brian
- [Cfrg] matching AES security D. J. Bernstein
- Re: [Cfrg] matching AES security Robert Moskowitz
- Re: [Cfrg] matching AES security Natanael
- Re: [Cfrg] matching AES security Tanja Lange
- Re: [Cfrg] matching AES security Paul Lambert
- Re: [Cfrg] matching AES security Benjamin Black
- Re: [Cfrg] matching AES security Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] matching AES security Phillip Hallam-Baker
- Re: [Cfrg] matching AES security Watson Ladd
- Re: [Cfrg] matching AES security Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] matching AES security Michael Hamburg
- Re: [Cfrg] matching AES security Andrey Jivsov
- Re: [Cfrg] matching AES security Andy Lutomirski
- Re: [Cfrg] matching AES security Andy Lutomirski
- Re: [Cfrg] matching AES security Michael Hamburg
- Re: [Cfrg] matching AES security Sandy Harris
- Re: [Cfrg] matching AES security James Cloos
- Re: [Cfrg] matching AES security Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] matching AES security Nico Williams
- Re: [Cfrg] matching AES security Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] matching AES security Phillip Hallam-Baker
- Re: [Cfrg] matching AES security Watson Ladd
- Re: [Cfrg] matching AES security Johannes Merkle
- Re: [Cfrg] matching AES security Robert Moskowitz
- Re: [Cfrg] matching AES security Brian Smith
- Re: [Cfrg] matching AES security Peter Gutmann
- Re: [Cfrg] matching AES security Andrey Jivsov
- Re: [Cfrg] matching AES security Watson Ladd
- Re: [Cfrg] matching AES security Alex Elsayed
- Re: [Cfrg] matching AES security Peter Gutmann
- Re: [Cfrg] matching AES security Alyssa Rowan
- Re: [Cfrg] matching AES security Phillip Hallam-Baker
- Re: [Cfrg] matching AES security Dan Brown
- Re: [Cfrg] matching AES security Dan Harkins
- Re: [Cfrg] matching AES security Ilari Liusvaara
- Re: [Cfrg] matching AES security D. J. Bernstein