Re: [Cfrg] [TLS] 3DES diediedie

Joachim Strömbergson <joachim@secworks.se> Wed, 07 September 2016 07:50 UTC

Return-Path: <joachim@secworks.se>
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 8B4C212B0B4 for <cfrg@ietfa.amsl.com>; Wed, 7 Sep 2016 00:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 G9u8A4nYuWaZ for <cfrg@ietfa.amsl.com>; Wed, 7 Sep 2016 00:50:34 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE5712B324 for <cfrg@irtf.org>; Wed, 7 Sep 2016 00:50:34 -0700 (PDT)
Received: from Knubbis.local (unknown [80.252.219.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 0D31F2050E; Wed, 7 Sep 2016 09:50:32 +0200 (CEST)
Message-ID: <57CFC6C6.5030006@secworks.se>
Date: Wed, 07 Sep 2016 09:50:30 +0200
From: Joachim Strömbergson <joachim@secworks.se>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Derek Atkins <derek@ihtfp.com>
References: <20160906114030.18292816.41703.89024@ll.mit.edu> <57CEAE6F.1040608@secworks.se> <sjmeg4wvjut.fsf@securerf.ihtfp.org>
In-Reply-To: <sjmeg4wvjut.fsf@securerf.ihtfp.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/wm0xpE7WtywYmN7rnV1c0leOCaA>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Hilarie Orman <hilarie@purplestreak.com>
Subject: Re: [Cfrg] [TLS] 3DES diediedie
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: Wed, 07 Sep 2016 07:50:38 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Derek Atkins wrote:
> I'm afraid I have to disagree here.  What's it's done is pushed 
> yesterday's computation capabilities into smaller and smaller
> devices, lower and lower on the food chain.  C.f. my previous email
> about a light bulb.  Cost is definitely a concern, as well as power
> and performance.

So far this year I've seen things like light bulbs, tyre pressure
sensors, tooth brushes, power meters, car door side panel controls,
melody gift cards that contain ARM based MCUs. It is not a decade away,
it is today.


> So while yes, we can say "let's use an ARM Cortex Mx", that really 
> doesn't work in all cases.  So sure, we can wait yet another decade
> for Moore's law to catch up with today's smart devices, but I suspect
> then we'll have yet another class of even smaller devices.

And I claim that for a huge number of use cases, ARM based devices are
already there. In terms of price, in terms of power.

And, as I've tried to explain. Simpler (less gates) designs don't scale
down very good with Moore's law if the die size is I/O bound. You just
get more unused space (which is why MCUs gets more internal RAM memory
since that is what you easily can use the void for.)

What you gain is lower power consumption. Many MCUs still need to
support fairly high voltage I/Os (which makes the I/Os bigger on the die).

What I tried to show is that ARM based devices can do the same
processing as a PIC with the same power consumption. Some of them also
sports very good power modes that allows you to control the power
consumption. And specifically for AES you can get much better
performance and very much better power consumption with an AES core.
(There are some MSP430 and 8051 based 8-bit MCUs that also have AES
cores too.)


>> The implementation of the cipher is rarely the components that make
>> or break the design. And in terms of development cost, deployment
>> cost and the effort to convince buyers to trust something that is
>> not AES, they all increase. Things you also need to account for at
>> system design time.
> 
> True..  but it can certainly be a factor.

I don't think so. Look, I really love crypto stuff. And the Trivium
eSTREAM cipher in the embedded portfolio for example is a beautiful
design that shows what you can do with limited resources. Grain is
another lightweight cipher, and it has gotten some traction I think.

But unless you can get much better properties for your product in terms
of cost and performance (including battery life), you will have an
uphill battle in comparison to AES as your symmetric cipher.

At least where I live in Europe you have huge smart grids with up to
millions of power meter nodes in the network. All of them talks ZigBee
SmartEnergy or things close to it. That means AES in CCM mode. This is
what the customers are used to and expect. And it is what the developers
are used to, the support and service organizations are used too.

Coming to these orgs with a device that uses some other cipher requires
not only integration costs, but also the psychological cost of trying to
explain why 48 rounds of SIMON is better than 10 rounds of AES-128 that
has been tested, analyzed since 1997.


Researching lightweight ciphers is cool and good. But I don't expect to
see many symmetric primitives gain any major deployment. Where I think
we have a clear need for IoT is lightweight asymmetric primitives. Key
exchange, signatures etc. Too many devices use PSK simply because key
exchange is too costly, takes too long time.

If my work experience is anything to go by, if there are going to be any
new primitives being used, it will be from NaCl, that is Salsa och
Chacha, Poly1305 and Curve25519.


Where I specifically see a big need is for a good standardized firmware
update mechanism. Today everybody either rolls their own firmware
mechanism or get a (broken) one from their MCU vendor. I think there
were a new working group for this within the IETF. Can't remember and
can't find. But I think that it a very good idea.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim@secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJXz8bGAAoJEF3cfFQkIuyNjsIQAJIrf5q8jJ7ItJcTFd37Tw/Z
yvH2cBLjJXqO08PMqcgrzJZNgX+yHboNxzUct6fak+DFXZhoECgrVk+HnNM6SAj1
kvNvC/YFzRW49yGPJnzylf8KvdzTxqbfL2Yf/7ZqmuRjwcpm37ytLKjMLpJWhmRG
xehFSNdhew7JvwwnKD5/dZRP13TSrBIuBAMxvPWsvnS6fQk+gS/Tbxn/Q1YzKJ9c
Y2oHR4eigRkStg8yycIyNMjZ4BZjplc5KdsIoH4uyFixPUOAGj1b3g1gKyez7gRq
xygfpY0fORGX9n2Np/vdeV3nwol4ms+KaYgiQwmDz2rXEo8FD9oWDh3rjKYpyowx
3C2zHbd3OkpxkVCZV7AF0I83CFhR7rziqEhU9PJ4CD4I8te/ZTeAnehWBLWVipqv
8xuNt7QYYWaQhs/zLJhxr1PyueaxJCP+6rTFoa6p+x7mk+4EAdbbXX9nxbSIUrcr
+fw6jqRoDbBTDmVJOqVjeZHB/3Mm20v2fyWqngjR2Wm/jpJxYp14rXWdKEimC/2w
lOzVXy4g3XiCpEh1ouHagUQriXLbilAvHd731R6MLt/+c4ZsWd7hgQvGVsgs04d5
IG8C+nOOyCDyfLFhVUKYXQA4HafU5qojouDdVz0x6nmVKec510NvEbTvBjdWZtko
RsB20rCIj3Aa2R7//kSh
=WL5X
-----END PGP SIGNATURE-----