Re: [Cfrg] matching AES security

Michael Hamburg <> Wed, 30 July 2014 20:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 600131A03CF for <>; Wed, 30 Jul 2014 13:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.555
X-Spam-Level: *
X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nGJwS0PUk417 for <>; Wed, 30 Jul 2014 13:26:30 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E39F31A0326 for <>; Wed, 30 Jul 2014 13:26:29 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 07B6A3AA12; Wed, 30 Jul 2014 13:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=sldo; t=1406751972; bh=Nk6CyLEIGcJ7TT15HEubvwFDZx9jKa2nCDlHUy4fOyk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=e7R7Nj9m9Z+12K2kMOOU/RSiLz3y4MAfyZCob+nHGFDSdCgLqnzSfhPdSNAnO/SEX kWC1UOOCPXD+M3y/nNWb0X1vaZ2H6uHgWnjKJDKOic/mmTsbS6KOesKsr/XvjHnOvE u/FbFpK7CnhNt4PRW+7pTCz8gVmtN2VS97Azelek=
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Hamburg <>
In-Reply-To: <>
Date: Wed, 30 Jul 2014 13:26:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Andy Lutomirski <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "" <>
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: Wed, 30 Jul 2014 20:26:31 -0000

On Jul 30, 2014, at 12:45 PM, Andy Lutomirski <> wrote:

> On Wed, Jul 30, 2014 at 11:24 AM, Blumenthal, Uri - 0558 - MITLL
> <> wrote:
>> Is the attack DJB mentioned an attack on AES?  No: AES matches the PRP
>> security definition. Is it an attack on Salsa20? No: it meets the security
>> claim.
>> Rather it's the obvious point that a man who strains half a lake has half
>> the fish.
>> This has been pointed out before on this list, and is really on the level of
>> an exercise in probability.
>> In that case (probability game) this attack does not seem realistic, let
>> alone plausible.
>> How many plaintext pairs can you store (alternatively, which one "master"
>> plaintext would you use)? For how many keys? How do various encryption modes
>> impact your ability to search your tables (i.e., might using IV interfere
>> with it)? How are you planning to identify that magic plaintext encryption
>> in the traffic stream? What do your resulting probabilities look like in
>> real world, after all of this has been taken into account?
>> I won't dump my AES-128 just yet. :-)
> In my opinion, this approach to crypto has been inappropriate for
> quite some time.  Despite the fact that, theoretically, there were
> nice attacks against MAC-then-encrypt, people kept using it because
> they couldn't imagine how those attacks could work in the "real
> world".  That didn't go so well.
> If people start using 256-bit keys, then these attacks are a
> non-issue.  Or someone could try to find a protocol that is *provably*
> immune with 128-bit keys.  But let's stop relying on our own failures
> to image how these attacks might work.
> —Andy

I’s really hard to get tight security bounds.  To start with, you’ll need something stronger than the standard PRF/PRP assumptions; maybe ideal ciphers would be enough?  Likewise with EC signatures, even in the ROM the bounds are really far from tight.

But yeah, 256-bit symmetric ciphers are cheap.  If the small performance difference doesn’t matter much to you, then just use them everywhere.

— Mike