Re: [TLS] [Cfrg] 3DES diediedie

[Peter Gutmann <[e-mail]>]

David McGrew (mcgrew) <[e-mail]> writes:

>Most of the lightweight “designed for IoT” block ciphers have a 64 bit block
>size (and sometimes even smaller); see for instance Table 1.1 of
>https://eprint.iacr.org/2013/404.pdf So perhaps what the Internet needs here
>is sound guidance on how to use 64-bit block ciphers.   Best practices here
>include both mandatory rekeying well below the birthday bound and/or the use
>of secure beyond the birthday bound modes of operation such as Iwata’s CENC.

IoT devices are, pretty much by default, insecure.  And I mean, really, really
insecure, I've heard phrases like "hack like it's 199x" a number of times
during talks on all the holes people have found in these things.  In addition,
the reason why devs are using lightweight ciphers in IoT devices is because
they know that their device can't use anything more powerful, in the same way
they they know that a strcpy() into a ten-byte fixed-size buffer is a good way
to decode network packets.

Looking at it from the other side, your typical IoT device will be sending,
for example, a 12-byte message every 15 minutes, meaning it'll take, if my
calculations are right, just under two million years to collect the 785GB of
data required to perform the attack.

So you've got something where the devices aren't vulnerable to the problem
(and nor, in any practical case, is anything else), for which the devs
involved won't even know that any guidance on the situation exists, and for
which, if anyone really wants to attack them, they can use any of the dozens
of insecure-by-design holes that are present in the device to own the whole
thing, at which point what you do with your crypto becomes meaningless.

So what you're proposing is essentially a non-solution to a non-problem...
still, if you feel like writing the memo for it, don't let me stand in your
way.

Peter.