Re: [TLS] [Cfrg] 3DES diediedie

Joachim Strömbergson <joachim@secworks.se> Tue, 06 September 2016 06:36 UTC

Return-Path: <joachim@secworks.se>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B744812B11D for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 23:36:31 -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=unavailable 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 KGB9gEIzlp6g for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 23:36:30 -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 D60F512B0B4 for <tls@ietf.org>; Mon, 5 Sep 2016 23:36:29 -0700 (PDT)
Received: from Knubbis.local (unknown [80.252.219.34]) by mail.frobbit.se (Postfix) with ESMTPSA id A80D422E11; Tue, 6 Sep 2016 08:36:27 +0200 (CEST)
Message-ID: <57CE63E9.2080100@secworks.se>
Date: Tue, 06 Sep 2016 08:36:25 +0200
From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= <joachim@secworks.se>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Hilarie Orman <hilarie@purplestreak.com>
References: <201609051906.u85J6jWT012165@rumpleteazer.rhmr.com>
In-Reply-To: <201609051906.u85J6jWT012165@rumpleteazer.rhmr.com>
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/tls/KyThU5P0aq0LkjaYYzVipElFfRg>
Cc: cfrg@irtf.org, tls@ietf.org
Subject: Re: [TLS] [Cfrg] 3DES diediedie
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2016 06:36:32 -0000

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

Aloha!

Hilarie Orman wrote:
>> On 31 August 2016 at 20:48, Hilarie Orman
>> <hilarie@purplestreak.com> wrote:
> 
>>>> From: Brian Sniffen <bsniffen@akamai.com>
> 
>> The question is not "how much hardware?" but "price?" - with  ARMs 
>> including h/w AES coming in at $2 for a single unit, its hard to
>> explain why you\d want to use a less powerful CPU...
> 
> 
> Power.
> 
> Hilarie

Did you look at the ARM Cortex M0+ Gecko Zero I pointed to? I'd
recommend that you compare its power consumption to a PIC.

The PIC is manufactured using larger geometries that consumes more
power/gate/MHz. The Gecko Zero has more power modes allowing it to
enable/disable different functions very fast, and is able to scale its
own internal clock frequency very flexibly. The Gecko Zero (and other
M0+ devices) can also do more/cycle so that total power up time is
shortened, saving power.

Specifically (since we talked about it before), the AES core in the
Gecko Zero takes about 50 cycles to process one block (and the CPU core
can be powered down at the same time). Googling for cycles to perform
AES on PIC I found:

Encryption
PIC16F877 : 3834 cycles
PIC16F84 : 7157 cycles

https://edipermadi.wordpress.com/2008/02/09/an-aes-implementation-on-pic16f877/

So on the PIC you need to have the CPU core powered up and running about
80 times longer (in terms of cycles) than the Gecko needs to run its AES
core.

And even if you don't have an AES core, the ARM can do AES in fewer
cycles. This one shows 2270 cycles for AES-128

http://www.cryptovia.com/ARM_Thumb_AES.html


Selecting 8/16 bit MCUs like AVR, PIC, 8051 in 2016 for power reasons
without looking at modern 32-bit MCUs based on ARM or MIPS is a mistake
imho.

- -- 
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/

iQIcBAEBCAAGBQJXzmPpAAoJEF3cfFQkIuyNW74P/3CuHjDaD+OnU4RHVemzDgKZ
rRvDa/3ekLVDDKUQUP5UhPLolg8tn7L1pPWwT8MU+aY2T7TUyRmwG8dukQlTdk1G
7jZi7xE5efEY6vOHDH2s50nL166vRQAC2dBpSFqJQ4SXXM23qkViCW1JI64jvLmg
KVryfU0LWSKZc0QB3Yta0g4nLwkBWIUywpxWOiGT0y54P6I6YjLKavnxvToOOnxw
wdO6WDSNx8fBCOwf4Sb8cVmX77dYN+JywRgOUWfT9uweUWuQZQe3MujLRbNd8uNY
+9qlwb7uG9I/OLypmu/7hHpwb5U/kbP04u6kbedG1h+TT/QxwU+vOwz9nRytvHDL
kOj3VYZnmWQFgcr/fvmXMiUL3s9qQWubIH151JLylDQF1dC+QhvIPlHfGlKQXKWv
8+ZfDtLAAHIagDqdMNO7bX7I2NujqO5P7XmLgw0p6GMwgV2hrdX8Jw6t5sp/xEqc
9pv+hMJIYT3QzWm9XZbjPpkoSEmt4yHciZkQuzaZyShLf3M76mEC/HnpYCHdp6JQ
5YcKwfBTX6WpFQ/PPhEu9NcTVHu2z0WxIPsv4O3+FUdXWtBPzHto8D6k8m3hpwOw
d/GwX0HMUIaldA2l1o+0ZWKmO4Ov81EDM3bCOeUzSjp4ZE33S3TkXgGG35MIX29T
7js19Jx4tVKQYimJbJRO
=N7Q6
-----END PGP SIGNATURE-----