Within this line of thought, an unlimited-key-use-diediedie would have far more value. An RFC precisely defining a set of key data limits would address both this 3DES issue as well as AES and any other cipher. As cited on https://sweet32.info/ , data limits is a primary way Mozilla is dealing with this attack.
Dave On Monday, August 29, 2016 09:26:18 am Rene Struik wrote: > I think it is a mistake to think that simply using block ciphers with a > larger block size is enough to counter attacks, as the literature on > successful side channel attacks on such block cipher demonstrates. The > real message is that one should not reuse keys ad infinitum, which > unfortunately seems hard to sink in. > > Singling out 3-DES in this respect does not seem to tackle the real > issue (which is a system security issue often only paid lip service to > in practice). > > Rene > > On 8/29/2016 8:56 AM, Joachim Strömbergson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Aloha! > > > > As a side note, there has been a bunch of lightweight block ciphers > > suggested the last few years, most of them with a block size of 64 bits. > > And there has been discussion on IETF maillists about IETF accepting > > them. For example the SIMON and SPECK ciphers. These ciphers can have > > block sizes as small as 32 bits. > > > > https://www.cryptolux.org/images/a/a0/Beaulieu-DAC2015.pdf > > https://eprint.iacr.org/2015/209.pdf > > > > Yours > > JoachimS > > > > > > > > David McGrew (mcgrew) wrote: > >> Hi Peter, > >> > >> You make a bunch of good points. But it is also worth noting that > >> some people feel that current crypto standards, including IETF > >> standards, are suitable for IoT. See for instance slides 8 and 9 of > >> Daniel Shumow's talk at NIST’s LWC workshop last year: > >> http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.pdf > >> Also, CoAP isn’t on his list, but it could be, and it uses DTLS. So > >> while I agree with you that overuse of a 64-bit block cipher is far > >> from the biggest security concern for IoT, the IETF should expect its > >> protocols to be used in some IoT scenarios. > >> > >> The malleability of the term IoT is causing trouble here. Slide 6 > >> of Daniel’s talk is quite revealing. To my thinking, by definition > >> IoT devices are connected to the Internet in some way. > >> > >> David > >> > >> > >> > >> On 8/28/16, 8:01 AM, "Peter Gutmann" <pgut...@cs.auckland.ac.nz> > >> wrote: > >> > >>> David McGrew (mcgrew) <mcg...@cisco.com> writes: > >>> > >>>> 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. > >>> But the IETF has a long history of creating standards that > >>> completely ignore IoT. I can't think of a single general-purpose > >>> IETF security standard (TLS, SSH, IPsec, etc) that has any hope of > >>> working with IoT devices (say a 40Mhz ARM-core ASIC with 32kB RAM > >>> and 64kB flash). This is why the ITU/IEC and a million > >>> lesser-known standards bodies are all busy inventing their own > >>> exquisitely homebrew crypto protocols, most of which make WEP look > >>> like a model of good design. > >>> > >>> (I've always wanted to sit down and design a generic "encrypted > >>> pipe from A to B using minimal resources" spec, and I'm sure many > >>> other people have had the same thought at one time or another). > >>> > >>> So it seems like you've got: > >>> > >>> - The "TLS = the web" crowd (browser vendors and the like) who will > >>> implement whatever's trendy at the moment and assume everyone has a > >>> quad-core 2GHz CPU with gigabytes of RAM and access to weekly live > >>> updates and hotfixes. > >>> > >>> - Embedded/SCADA folks who need to deal with 10-15 year product > >>> cycles (see my TLS-LTS draft for more on this) and are kind of > >>> stuck. > >>> > >>> - IoT people, who can't use any standard protocol and will get the > >>> least unqualified person on staff to invent something that seems OK > >>> to them. > >>> > >>> I'm not sure that a draft on theoretical weaknesses in 64-bit block > >>> ciphers is going to affect any of those... _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
