Re: [Cfrg] matching AES security

Andy Lutomirski <> Wed, 30 July 2014 19:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 952311A0340 for <>; Wed, 30 Jul 2014 12:46:14 -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 T6EcPVSZV_Py for <>; Wed, 30 Jul 2014 12:46:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 116921A01AA for <>; Wed, 30 Jul 2014 12:46:11 -0700 (PDT)
Received: by with SMTP id s18so1319017lam.28 for <>; Wed, 30 Jul 2014 12:46:10 -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:from:date :message-id:subject:to:cc:content-type; bh=MKkg6edQJ5os7u301tSyrN30wuvHeuttrLjjfXSpxJ0=; b=TEP9AJTnEg7kDCCY3/xVaa6FkcCp/kbN0ca2udrq39Wwy4jcQzNDjMt2xpBfdSC3/c i5GD1h4mAN3Yf1xLN8HI/X5edxnHP2nxPs9IaNqvmZ9eXuZ0dX4ruDac07wqpVNwnliX uOaJWetWtAPznpTX8untGks0NmztyFyUObQ4p2DzKZhrBfCFnsCPZh+mm5Ds4DvzJOEf AAINlMoX7nfHGZhylyu2eQ1BTk/SnjAHtw1fRR3k9s2Kvc87pUUCuDZNmzmjZfWM1HBb ep5sDFf4TLUx4qbLG2SQkjwAuVje8Nljaqd1tSbp1/5k5uFYhsh2iiBNptHA9AKwrVGh Z6HQ==
X-Gm-Message-State: ALoCoQnNTTN+teuwQAJhP76FU2QkU8dZT8RUc5wXDJFzgaLjTXcH4+Gdlx7IKVhrhKGNincSVQsr
X-Received: by with SMTP id n4mr6781055lbn.46.1406749570247; Wed, 30 Jul 2014 12:46:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 30 Jul 2014 12:45:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Andy Lutomirski <>
Date: Wed, 30 Jul 2014 12:45:50 -0700
Message-ID: <>
To: "Blumenthal, Uri - 0558 - MITLL" <>
Content-Type: text/plain; charset="UTF-8"
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 19:46:14 -0000

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.