David McGrew (mcgrew) <mcg...@cisco.com> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
