Re: [Cfrg] matching AES security

Natanael <natanael.l@gmail.com> Wed, 30 July 2014 14:25 UTC

Return-Path: <natanael.l@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 3A1041A0103 for <cfrg@ietfa.amsl.com>; Wed, 30 Jul 2014 07:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-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 T7ljYOmCqkcy for <cfrg@ietfa.amsl.com>; Wed, 30 Jul 2014 07:25:17 -0700 (PDT)
Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C921A0115 for <cfrg@irtf.org>; Wed, 30 Jul 2014 07:25:14 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id la4so1913829vcb.9 for <cfrg@irtf.org>; Wed, 30 Jul 2014 07:25:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yvj4LwsYK8JxjszAIFwD4qLdf+xeDT0RmO7AlVsMYBg=; b=0x98jx05GJBXYsoYabt9Nm7joWigP7MYLswvn0MY+dOce+tYfNGb6jvv6YL93qf/rb iYr+7sJQilollCB+bPKpvasHAQh5A8GzXue7ynLex2CfglVhWZ5bL5Nkqyg3mfmE/lio piDWWiuHrvAtXnDtZ6obkENMgImwtnUAS9tjyx7djRVOdFWCtUc4V2nCrUH0/ZloCOpY 8r3sCKu4z42MexHZfdu5rTYEgcs0Q4pz9nRLvex+ABOIJRv8PbK7xNXGvHrJrBVIb+pE /wxp1uihbqUb1bZXmpT2uwpwR87xp2gD7TPWRnt9O+OAcmNoiVNdU5FXNKsWDyjCJbae +HBQ==
MIME-Version: 1.0
X-Received: by 10.52.37.81 with SMTP id w17mr1475360vdj.95.1406730313093; Wed, 30 Jul 2014 07:25:13 -0700 (PDT)
Received: by 10.58.111.106 with HTTP; Wed, 30 Jul 2014 07:25:12 -0700 (PDT)
Received: by 10.58.111.106 with HTTP; Wed, 30 Jul 2014 07:25:12 -0700 (PDT)
In-Reply-To: <53D8FBDB.4060601@htt-consult.com>
References: <20140730123336.29011.qmail@cr.yp.to> <53D8FBDB.4060601@htt-consult.com>
Date: Wed, 30 Jul 2014 16:25:12 +0200
Message-ID: <CAAt2M19w_Gx2BWMhw22hS6eDQ2RoWbD+0P1Uzh3HxZkgPe_7uw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Content-Type: multipart/alternative; boundary="20cf307ca0f49b5c1804ff69ece0"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/PiYaD9mu4s8lBEYHOEh4GPgDFOI
Cc: 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: Wed, 30 Jul 2014 14:25:21 -0000

Den 30 jul 2014 16:06 skrev "Robert Moskowitz" <rgm-sec@htt-consult.com>:
>
>
> On 07/30/2014 08:33 AM, D. J. Bernstein wrote:
>>
>> Blumenthal, Uri - 0668 - MITLL writes:
>>>
>>> IMHO, the logic/reason of matching security levels of the
>>> cryptographic algorithms employed in a protocol suite is fairly
>>> obvious and does not need an explicit justification.
>>
>> Let's think through what "matching security levels" actually means for
>> matching elliptic curves with AES.
>>
>> In the foreseeable future there will be billions of devices that users
>> are relying on for cryptographic computations, and it's easy to imagine
>> that a typical device will use at least one new key every minute, i.e.,
>> a million new keys within two years. That's more than 2^50 keys overall.
>
>
> Dan,
>
> Please explain what typical device will use at least one new key every
minute?
>
> In the typical devices I work with there will be at best one ECDHE
exchange per day. Sometimes only once per month. (one message/5min = 312
short messages/day to protect with AES-CCM or GCM). (we are working on
changing once per life of sensor)
>
> Now if you look at the server side that is receiving messages from 10,000
fielded sensors and thus has 10,000 ECDHE exchanges/day (or per month),
then the risk is a tad different?

It is not inconceivable that all kinds of mobile devices (not just
smartphones, but smartglasses, watches, shoes, your backpack, home
automation devices, electric cars which talk with every other large vehicle
nearby, etc) will be part of traffic anonymization networks like Tor and
I2P which frequently establishes new encrypted tunnels, that they'll be
using instant messengers with various OTR like protocols which rekey often,
so be part of radio mesh networks (see apps like Serval), etc... Then
there's file sharing (Flud is a nice torrent client for Android). And don't
forget randomized cover traffic to disrupt traffic analysis.

That's not even considering home servers which will do all of the above and
much more.

Few devices will only maintain a small set of connections over their
lifetimes, and many will be rekeying often for the sake of PFS (perfect
forward secrecy), etc...

This may be 10 years off before it becomes common (a large fraction of
users doing it), but it's highly likely to happen. The total number of
encrypted links will increase very drastically over time.

Your sensor may not be affected, but the rest of the world will be.