Re: [Cfrg] matching AES security

Robert Moskowitz <rgm-sec@htt-consult.com> Thu, 31 July 2014 13:51 UTC

Return-Path: <rgm-sec@htt-consult.com>
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 3CAD91B2816 for <cfrg@ietfa.amsl.com>; Thu, 31 Jul 2014 06:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 raURrqEmuvsH for <cfrg@ietfa.amsl.com>; Thu, 31 Jul 2014 06:51:15 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id A570A1A0020 for <cfrg@irtf.org>; Thu, 31 Jul 2014 06:51:14 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 03668633DB; Thu, 31 Jul 2014 13:51:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQeCbNhucgki; Thu, 31 Jul 2014 09:51:03 -0400 (EDT)
Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm-sec@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id E9AE762A7B; Thu, 31 Jul 2014 09:51:02 -0400 (EDT)
Message-ID: <53DA49C6.4070504@htt-consult.com>
Date: Thu, 31 Jul 2014 09:51:02 -0400
From: Robert Moskowitz <rgm-sec@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Michael Hamburg <mike@shiftleft.org>, Andy Lutomirski <luto@amacapital.net>
References: <20140730123336.29011.qmail@cr.yp.to> <CA+Vbu7wwSUOJgHmGZu3ii1sn9ZfmqsWUHimYVd3wNX=RgxbaBg@mail.gmail.com> <CACsn0cmofOFFOc-EFyu5=kMVyhLCwTMudQ607zH1h9m9Q5ve1Q@mail.gmail.com> <CFFEAE61.18259%uri@ll.mit.edu> <CALCETrVzQaE6ZVCV6-n060e4jqcbio_TWuOGyM5hAKLPpb-oDQ@mail.gmail.com> <F2C352B4-2474-46F3-A2F4-EE6CFE54F65A@shiftleft.org>
In-Reply-To: <F2C352B4-2474-46F3-A2F4-EE6CFE54F65A@shiftleft.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/YvBNucNAhl4HYlkGHvwSk17XK5s
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
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 13:51:20 -0000

On 07/30/2014 04:26 PM, Michael Hamburg wrote:
> On Jul 30, 2014, at 12:45 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
>> On Wed, Jul 30, 2014 at 11:24 AM, Blumenthal, Uri - 0558 - MITLL
>> <uri@ll.mit.edu> 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.

Except the cost to change standards where they are 'hardwired' in. I 
have to figure out how to expand the cipher choice for 802.15.4 without 
really breaking the MAC Header.  Only 3 bits for the cipher selector and 
0 - 6 already used...

I should use the September meeting in Athens to socialize how to address 
this...

The whole family of 802.15.N (N={4, 6, 7, maybe8}) are like this. Then 
IEEE 1901.2 basically copied the 802.15.4 MAC.

But this list is about selecting good crypto.  Elsewhere we need to 
think really hard about USING good crypto.