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.
- [Cfrg] matching AES security D. J. Bernstein
- Re: [Cfrg] matching AES security Robert Moskowitz
- Re: [Cfrg] matching AES security Natanael
- Re: [Cfrg] matching AES security Tanja Lange
- Re: [Cfrg] matching AES security Paul Lambert
- Re: [Cfrg] matching AES security Benjamin Black
- Re: [Cfrg] matching AES security Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] matching AES security Phillip Hallam-Baker
- Re: [Cfrg] matching AES security Watson Ladd
- Re: [Cfrg] matching AES security Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] matching AES security Michael Hamburg
- Re: [Cfrg] matching AES security Andrey Jivsov
- Re: [Cfrg] matching AES security Andy Lutomirski
- Re: [Cfrg] matching AES security Andy Lutomirski
- Re: [Cfrg] matching AES security Michael Hamburg
- Re: [Cfrg] matching AES security Sandy Harris
- Re: [Cfrg] matching AES security James Cloos
- Re: [Cfrg] matching AES security Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] matching AES security Nico Williams
- Re: [Cfrg] matching AES security Blumenthal, Uri - 0558 - MITLL
- Re: [Cfrg] matching AES security Phillip Hallam-Baker
- Re: [Cfrg] matching AES security Watson Ladd
- Re: [Cfrg] matching AES security Johannes Merkle
- Re: [Cfrg] matching AES security Robert Moskowitz
- Re: [Cfrg] matching AES security Brian Smith
- Re: [Cfrg] matching AES security Peter Gutmann
- Re: [Cfrg] matching AES security Andrey Jivsov
- Re: [Cfrg] matching AES security Watson Ladd
- Re: [Cfrg] matching AES security Alex Elsayed
- Re: [Cfrg] matching AES security Peter Gutmann
- Re: [Cfrg] matching AES security Alyssa Rowan
- Re: [Cfrg] matching AES security Phillip Hallam-Baker
- Re: [Cfrg] matching AES security Dan Brown
- Re: [Cfrg] matching AES security Dan Harkins
- Re: [Cfrg] matching AES security Ilari Liusvaara
- Re: [Cfrg] matching AES security D. J. Bernstein