Re: [TLS] Deprecating more (DSA?)

[Bill Frantz <[e-mail]>]

On 4/19/14 at 10:44 AM, [e-mail] (Watson Ladd) wrote:

>On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz <[e-mail]> wrote:
>>The other use case to always keep in mind is limited performance devices.
>>With the Internet of Things, we will continue to see new 8 bit, and possibly
>>even 4 bit processors as manufactures drive in the direction of the small,
>>low power, and cheap. These devices will be much safer if they have
>>authentication and replay protection. While secrecy is probably not as
>>important, it might also be vital in certain applications of these devices.
>
>So AES-CCM fixes one issue (the wire PDU), but we really, really, need
>a hash for the handshake. These devices also might not even have
>random number generators that aren't deterministic or a counter to
>avoid replays. There's a lot to be done: benchmarking, thinking hard
>about protocol problems that might cause issues, determining what we
>can and cannot provide.

One way to address the random number problem is to use the 
protocol that most web sites used with SSL. In that protocol, 
the client generated the random number and encrypted it with the 
server's public key. With the Internet of Things (IoT), having 
the controller end, which usually has a UI and lots of 
opportunity to generate good, unguessable numbers, generate the 
random number and the "thing" accept it might work well. A way 
to be agnostic about which was the client and which was the 
server is a protocol where if either end had good unguessable 
numbers, the resulting connection was secure would be nice. 
Getting perfect forward security in this environment might be hard.


>From some cursory research, hash functions are the real issue here.
>AES is byte-oriented, but Keccak is slow as molasses at big capacities
>sans SIMD. SHA-256 and friends all use 32 bit addition. Anyone got AVR
>benchmark data?

We should think about the performance requirements here. If I am 
instructing my Nest thermostat to warm up the house because i'm 
coming home, several seconds is more than acceptable. If I am 
building a light show for the bulbs in my living room, probably 
1/10 of a second is acceptable, and 1/100 of a second is 
certainly good enough.

>...
>
>With ECC life can get interesting. Drop the idea of RSA and DHE over
>F_p: too slow. 8 bit saturated arithmetic is probably the best.
>Timings are pretty slow: lots of verifications are a terrible idea.
>With PSK you don't need any of this, but I think that some embedded
>CPUs have the horsepower to do ECC, even at 8 bits. Make sure that
>this happens rarely, i.e. mostly static keys so results can be cached,
>and I think we are good. Due to memory pressure ladders are great.

Hmmm, my first read had ECC as Error Correction Codes but the 
paragraph reads a lot better if I read Elliptic Curve 
Cryptography. :-)

When we look at these processors, although the slower the clock, 
the less power required, there is a limit. If we run the clock 
much below 1 MHz, we have reached the point of seriously 
diminishing returns. 100 MHz is much more realistic. Since 
Elliptic Curve Cryptography gives more security/cycle than 
discrete logs, it is a very attractive technology.


>I've never seen a 4 bit micro. Anyone got details on what they are
>like and can do?

Look up the Intel 4004 for an early example. I don't know we 
will see the 4 bit wide ALUs again, but the drive for low cost, 
low power, and cheap is certainly still alive and well.

Cheers - Bill


-----------------------------------------------------------------------
Bill Frantz        | "The only thing we have to   | Periwinkle
[phone]      | fear is fear itself." - FDR  | 16345 
Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, 
CA 95032