IETF Logo Mail Archive

Re: [Cfrg] matching AES security

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 30 July 2014 23:47 UTC

Return-Path: <hallam@gmail.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 13BEA1A0657 for <cfrg@ietfa.amsl.com>; Wed, 30 Jul 2014 16:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 glEYI7kbEaiI for <cfrg@ietfa.amsl.com>; Wed, 30 Jul 2014 16:47:24 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DED01A03C4 for <cfrg@irtf.org>; Wed, 30 Jul 2014 16:47:24 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id hz20so1436159lab.8 for <cfrg@irtf.org>; Wed, 30 Jul 2014 16:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lvQyTlbnwVENi927TT3ORsgu42vv8Jv2dtqq3fQvEb4=; b=OQA30n3a56e33u4yUXej6M2WqTO6SqJdebkRQB6GnjcH6dF7cBRKEnSMr2IDvrsLlK Eh9E73cVi9n5Ed0jZaqPAKT/EBoG/K8JACTaxU5R1cUirU6m7bni/He9tLKsMewfmZm0 fYT2l6wyZthDKLzYeKCIk29OO1077m+mhyN3enpyoVfOqSphCEZ5H582drKwAFEz8ir0 46PiWc9QiQTNiCVu//pz1p4P3jfk0NLeTT+njs2rf8i3L547f4lAkcld46xSb+5yRIbH bZgIFGrist+z+eLPVB2v4NdWwLvX/V2Aop7pmul2KRZW8A3Rm5GeB2j3z/3hSksAK0Ns 2bcw==
MIME-Version: 1.0
X-Received: by 10.152.179.229 with SMTP id dj5mr5493784lac.97.1406764042633; Wed, 30 Jul 2014 16:47:22 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.122.50 with HTTP; Wed, 30 Jul 2014 16:47:22 -0700 (PDT)
In-Reply-To: <CAK3OfOjxSsxc95i6UVn3oW_Kdz3R92OUpGSmdfO=yFXnTpGvZQ@mail.gmail.com>
References: <20140730123336.29011.qmail@cr.yp.to> <53D8FBDB.4060601@htt-consult.com> <CAK3OfOjxSsxc95i6UVn3oW_Kdz3R92OUpGSmdfO=yFXnTpGvZQ@mail.gmail.com>
Date: Wed, 30 Jul 2014 19:47:22 -0400
X-Google-Sender-Auth: aWV2_BIBG7I779hyJaxaISSdtyY
Message-ID: <CAMm+Lwj9tfijR0n6Yw_tcr7hrs2ec48s+rVEKrEogyPvFPU9WA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/9WMM5zfT5NZ5xnsc6IzndgSgE8c
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Robert Moskowitz <rgm-sec@htt-consult.com>
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: Wed, 30 Jul 2014 23:47:26 -0000

On Wed, Jul 30, 2014 at 6:37 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Wed, Jul 30, 2014 at 9:06 AM, Robert Moskowitz
> <rgm-sec@htt-consult.com> wrote:
>> On 07/30/2014 08:33 AM, D. J. Bernstein wrote:
>>
>> Dan,
>>
>> Please explain what typical device will use at least one new key every
>> minute?
>
> Er, well, smartphone apps might well poll/get pushed to that
> frequently, altogether, with a new key per-poll/push.  Sure, the
> protocol involved might not generate a new key per-event, but if the
> protocol is TLS, then it will.
>
> DJB's point is that we should permit "odd" match-ups like AES-256 and
> Curve25519 _because_ AES-128 is weak in plausible scenarios.
>
> I'm having a hard time objecting to that!

I would accept it done right.

i.e. set up the keys with an initial 256 bit exchange and then use the
ephemeral 128 bit key as a mix-in to add PFS.

256 bit secrecy plus 128 bit forward secrecy would be good enough for
most applications.

v2.23.0 | Report a Bug | By Email