Re: [Cfrg] A little room for AES-192 in TLS?

Tony Arcieri <bascule@gmail.com> Mon, 16 January 2017 21:50 UTC

Return-Path: <bascule@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0AD1296BD for <cfrg@ietfa.amsl.com>; Mon, 16 Jan 2017 13:50:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.276
X-Spam-Level:
X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 y4FBRaz3gxcQ for <cfrg@ietfa.amsl.com>; Mon, 16 Jan 2017 13:50:53 -0800 (PST)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CFD1296AE for <cfrg@irtf.org>; Mon, 16 Jan 2017 13:50:53 -0800 (PST)
Received: by mail-ua0-x22f.google.com with SMTP id 96so90075839uaq.3 for <cfrg@irtf.org>; Mon, 16 Jan 2017 13:50:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MUXD5hiJFp4JBfjIj7Wlbvi7g7aya5fI5u/MIusBkqI=; b=sCLWHzNny3SQ7kwW42L4zXq4FqQ2aInfggwKKsbsFwbjTFC39gfr7ZRXj8UsqzhPEQ MJPyl6tanXB1oIMawYFNclRB1IM3cMpORKvqfRnAc3U4yXNCxD6XR06dV0Xy5U8QUBdm mnZbgxhqRHHHfCP092G4aeBtEQZ3lTCD9BiByTfIKSXDIsv5EPPU8F+UiV/cYyfurX+o czuadrOLXr99/UigA09nQ2lfqG/alezWCui+X5xGqdvJUrfraE4IQxr1uaLp4OKNgjdn ZqvqxdvvDwEdKGTW0tG4kjJueDulfP01T9H2lywwKheS5zhy69iEfQiTUlTcYZDHWsu3 +fIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MUXD5hiJFp4JBfjIj7Wlbvi7g7aya5fI5u/MIusBkqI=; b=ZMPXz/r/zK5Q631pcoViLjH7a8bov4h4gvfV214uhfl50SsukNBkBT3qVhfZu41pv3 ZRp/guhjQVSWu14+ZPu+9b5OGsZTrtMIZ3bwpjKqL39HiN5QGsImYa0QoKKiZ1jNME3v h0ULxz7eNiwq4bkb4nD8Zm4Uldo25Q8B6DMZNJIOjC9zlgLVVijA2asuxf9Dl3EkbAh1 ORQXUOC2ViMMwFfZQRE+V2UwkupLg2+8PgqFsW/qa2hRNfNxMV2l4AyzgxAV6U/sM+H5 MeFXAt867jnNHsL5iNs6+B/9rOKYABHknoHfvzjkSNnT3B2nTEKAbH+OxqzilsNhfZzq ItVA==
X-Gm-Message-State: AIkVDXLl6Dqvid/rrarts9tFjkNBkV5xV+bbHUR3lE1i5L4iZEIL15F8Z8xgi36pyrLj5Iz8JNLa+uX0h1BQMg==
X-Received: by 10.176.6.202 with SMTP id g68mr19612462uag.34.1484603452790; Mon, 16 Jan 2017 13:50:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.70.130 with HTTP; Mon, 16 Jan 2017 13:50:32 -0800 (PST)
In-Reply-To: <1484593651.5104.49.camel@quad>
References: <20170115205926.853FB60A6D@jupiter.mumble.net> <1484577818.5104.1.camel@quad> <D4A2A7CE.57FDF%john.mattsson@ericsson.com> <CABcZeBPGxT=9iiChy4PxD_zMHWcHU=AhCLoe7wEHHtryw2rfwg@mail.gmail.com> <D4A2B50D.7E040%kenny.paterson@rhul.ac.uk> <CAHOTMVJrHBn4AR7PCJ14xKYCVjdxF7SiswiOABX_g6A5gsQGDg@mail.gmail.com> <1484593651.5104.49.camel@quad>
From: Tony Arcieri <bascule@gmail.com>
Date: Mon, 16 Jan 2017 13:50:32 -0800
Message-ID: <CAHOTMV+Ac=mGeAsR7cerGYkarPJZXtVTMTF5Zra8y2kBdFYosw@mail.gmail.com>
To: Leonard den Ottolander <leonard-lists@den.ottolander.nl>
Content-Type: multipart/alternative; boundary=94eb2c1243ee6f9d7905463d2df0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/odA5YCM93AgMXIxgCHwTnIB1aqo>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] A little room for AES-192 in TLS?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jan 2017 21:50:55 -0000

On Mon, Jan 16, 2017 at 11:07 AM, Leonard den Ottolander <
leonard-lists@den.ottolander.nl> wrote:

> How about a scenario where an adversary is able to compromise the
> software in such a way that related keys are being generated
> occasionally and possibly even used for encryption of known plain text
> (protocol headers come to mind)? This scenario is assuming the adversary
> is not fully in control of the source code but is capable to inject
> subtle bugs "under the radar". Would AES-192 hold up better in such a
> scenario than AES-256?
>

Even in the event an attacker was able to pull off some sort of fault
attack and create related keys, as others have already noted the other side
will notice these keys are wrong and snap shut before the attacker can pull
off the rest of the attack. The next time you connect it will rekey. I
personally cannot think of any way to make TLS behave in such a way related
key attacks are even possible, even giving an attacker such a powerful tool
as precision fault attacks (and with such a powerful tool, they could
likely change the client's preferred ciphersuites as well).

This is a circular argument. AES-192 is not generally used because it is
> not in the specifications.


This argument holds not just for TLS, but pretty much any protocols that
use AES. In practice, nobody uses AES-192, because there is little reason
to choose it over either of the other options.


> Bruce Schneier wrote about this in 2009:
> https://www.schneier.com/blog/archives/2009/07/another_new_aes.html &
> https://www.schneier.com/academic/paperfiles/paper-rijndael.pdf
>
> In the blog he states "The attack exploits the fact that the key
> schedule for 256-bit version is pretty lousy -- something we pointed out
> in our 2000 paper -- but doesn't extend to AES with a 128-bit key."
>

Sounds like you just made an argument for AES-128.

-- 
Tony Arcieri