Re: [TLS] [Cfrg] 3DES diediedie

[Hilarie Orman]

>  On 31 August 2016 at 20:48, Hilarie Orman <hila...@purplestreak.com> wrote:

>  > >  From: Brian Sniffen <bsnif...@akamai.com>
>  >
>  > >  >>  From: Derek Atkins <de...@ihtfp.com>
>  > >  >>  Date: Wed, 31 Aug 2016 10:17:25 -0400
>  > >  >
>  > >  >>  "Steven M. Bellovin" <s...@cs.columbia.edu> writes:
>  > >  >
>  > >  >>  > Yes.  To a large extent, the "IoT devices are too puny for real
>  > >  >>  > crypto" is a hangover from several years ago. It was once true;
>  > for
>  > >  >>  > the most part, it isn't today, but people haven't flushed their
>  > cache
>  > >  >>  > from the old received wisdom.
>  > >  >
>  > >  >>  This is certainly true for AES, mostly because many small chips are
>  > >  >>  including AES accelerators in hardware.  It's not quite true for
>  > public
>  > >  >>  key solutions; there are still very small devices where even ECC
>  > takes
>  > >  >>  too long (and yes, there are cases where 200-400ms is still too
>  > long).
>  > >  >
>  > >  >>  > It pays to look again at David Wagner's slides from 2005, on
>  > sensor
>  > >  >>  > nets and crypto:
>  > >  >>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>  > >  >>  >
>  > >  >
>  > >  > Unattended sensors with wifi present an unsolved crypto problem.  They
>  > >  > can last 10 years on an AA battery without crypto, probably well less
>  > >  > than a year if they have to do any kind of encryption.  These things
>  > >  > will be everywhere, providing the data that will underly all kinds of
>  > >  > decision-making.
>  >
>  > >  Assuming there are *some* integrity requirements for the data, and that
>  > >  they are deploying 32-bit ARM with AES support (stipulating that ~every
>  > >  CPU will have AES support in a few years, as ~every CPU sold does
>  > >  today), we're talking about *either* an ECDHE negotiation every few
>  > >  months or a pre-shared key, good for ten years.
>  >
>  > >  AES-GCM with hardware support compares favorably to SHA-2 without
>  > >  hardware support, so if they've been able to last 10 years before, they
>  > >  should do just fine in the future.  The old devices won't last forever,
>  > >  and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
>  > >  for ten years after 1.3 is out.
>  >
>  > >  -Brian
>  >
>  > >  > Although much of the solution may lie in hardware innovation, the
>  > >  > world really does need minimal crypto algorithms.
>  > >  >
>  > >  > Hilarie
>  > >  >
>  >
>  > An ARM is far too much hardware to throw at "read sensor/munge data/send
>  > data".
>  >

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


>  >
>  > Hilarie
>  >

Power.

Hilarie

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hilarie Orman]

joac...@secworks.se writes:

>  Aloha!

Aloha auinala.

>  Hilarie Orman wrote:
>  > An ARM is far too much hardware to throw at "read sensor/munge
>  > data/send data".

>  No, they are not. The Cortex M0+ is aimed at these kinds of very simple
>  systems that runs for many years on a single battery.

>  Look at the STM32L0 series from ST for example. These devices can run on
>  energy harvesting and very tiny physically and very, very cheap (ten-ish
>  cents in high volume):

>  
> http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32l0-series.html?querycriteria=productId=SS1817

>  The STM32L021 has an AES-128 core. Not very fast (200+ cycles), but
>  several times faster than SW. You can also run the AES core wile the CPU
>  core is in power save mode.

>  Another example is the Zero Gecko from Silicon Labs. Same price range, a
>  huge number of power modes. And an AES core that is really fast. 50+
>  cycles for AES-128, which basically means 4 cycles/round (which implies
>  4 S-boxes)

>  
> https://www.silabs.com/products/mcu/32-bit/efm32-zero-gecko/pages/efm32-zero-gecko.aspx

For devices you refer to, how many AES blocks can they encrypt on a AA
battery, assuming that the usage is to encrypt one block every 10 minutes?

Hilarie

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hilarie Orman]

>  From: Brian Sniffen 

>  >>  From: Derek Atkins 
>  >>  Date: Wed, 31 Aug 2016 10:17:25 -0400
>  >
>  >>  "Steven M. Bellovin"  writes:
>  >
>  >>  > Yes.  To a large extent, the "IoT devices are too puny for real
>  >>  > crypto" is a hangover from several years ago. It was once true; for
>  >>  > the most part, it isn't today, but people haven't flushed their cache
>  >>  > from the old received wisdom.
>  >
>  >>  This is certainly true for AES, mostly because many small chips are
>  >>  including AES accelerators in hardware.  It's not quite true for public
>  >>  key solutions; there are still very small devices where even ECC takes
>  >>  too long (and yes, there are cases where 200-400ms is still too long).
>  >
>  >>  > It pays to look again at David Wagner's slides from 2005, on sensor
>  >>  > nets and crypto:
>  >>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>  >>  >
>  >
>  > Unattended sensors with wifi present an unsolved crypto problem.  They
>  > can last 10 years on an AA battery without crypto, probably well less
>  > than a year if they have to do any kind of encryption.  These things
>  > will be everywhere, providing the data that will underly all kinds of
>  > decision-making.

>  Assuming there are *some* integrity requirements for the data, and that
>  they are deploying 32-bit ARM with AES support (stipulating that ~every
>  CPU will have AES support in a few years, as ~every CPU sold does
>  today), we're talking about *either* an ECDHE negotiation every few
>  months or a pre-shared key, good for ten years.

>  AES-GCM with hardware support compares favorably to SHA-2 without
>  hardware support, so if they've been able to last 10 years before, they
>  should do just fine in the future.  The old devices won't last forever,
>  and probably can't run TLS 1.3---that's fine, TLS 1.2 will be with us
>  for ten years after 1.3 is out.

>  -Brian

>  > Although much of the solution may lie in hardware innovation, the
>  > world really does need minimal crypto algorithms.
>  >
>  > Hilarie
>  >

An ARM is far too much hardware to throw at "read sensor/munge data/send data".

Hilarie

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

[Hilarie Orman]

>  From: Derek Atkins 
>  Date: Wed, 31 Aug 2016 10:17:25 -0400

>  "Steven M. Bellovin"  writes:

>  > Yes.  To a large extent, the "IoT devices are too puny for real
>  > crypto" is a hangover from several years ago. It was once true; for
>  > the most part, it isn't today, but people haven't flushed their cache
>  > from the old received wisdom.

>  This is certainly true for AES, mostly because many small chips are
>  including AES accelerators in hardware.  It's not quite true for public
>  key solutions; there are still very small devices where even ECC takes
>  too long (and yes, there are cases where 200-400ms is still too long).

>  > It pays to look again at David Wagner's slides from 2005, on sensor
>  > nets and crypto:
>  > https://people.eecs.berkeley.edu/~daw/talks/sens-oak05.pdf
>  >

Unattended sensors with wifi present an unsolved crypto problem.  They
can last 10 years on an AA battery without crypto, probably well less
than a year if they have to do any kind of encryption.  These things
will be everywhere, providing the data that will underly all kinds of
decision-making.

Although much of the solution may lie in hardware innovation, the
world really does need minimal crypto algorithms.

Hilarie



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls