Hi Peter,
On 8/27/16, 8:21 AM, "Peter Gutmann" <pgut...@cs.auckland.ac.nz> wrote: >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. I don’t think you understood my point. IoT is about small devices connecting to the Internet, and IETF standards should expect designed-for-IoT crypto to be increasingly in scope. It is important to not forget about these devices, amidst the current attention being paid to misuses of 64-bit block ciphers, which was the ultimate cause of this mail thread. > >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. Gee, thanks. David > >Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
