Re: [Cfrg] matching AES security

Robert Moskowitz <rgm-sec@htt-consult.com> Wed, 30 July 2014 14:06 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 8839F1A008B for <cfrg@ietfa.amsl.com>; Wed, 30 Jul 2014 07:06:33 -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 uKUzStb2CQNF for <cfrg@ietfa.amsl.com>; Wed, 30 Jul 2014 07:06:31 -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 EE3DB1A007C for <cfrg@irtf.org>; Wed, 30 Jul 2014 07:06:30 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 7055A62B85 for <cfrg@irtf.org>; Wed, 30 Jul 2014 14:06:30 +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 4gE+lwKaLMqV for <cfrg@irtf.org>; Wed, 30 Jul 2014 10:06:20 -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 E9D8E62A76 for <cfrg@irtf.org>; Wed, 30 Jul 2014 10:06:19 -0400 (EDT)
Message-ID: <53D8FBDB.4060601@htt-consult.com>
Date: Wed, 30 Jul 2014 10:06:19 -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: cfrg@irtf.org
References: <20140730123336.29011.qmail@cr.yp.to>
In-Reply-To: <20140730123336.29011.qmail@cr.yp.to>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/IxQ9Xk-EInKmtwkTDQazOv7okj4
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:06:33 -0000

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?

thanks