Re: [TLS] [Cfrg] 3DES diediedie

On Thu, Sep 8, 2016 at 12:46 PM, Yoav Nir wrote: > > Good questions, no doubt. But I don’t think they can be answered. > > Someone is going to specify protocols and algorithms. This could be the > IETF. This could be the ITU, or IEEE, or some other SDO. Makes no > difference. > Someone is going t

Re: [TLS] [Cfrg] 3DES diediedie

> On 8 Sep 2016, at 7:08 PM, Kyle Rose wrote: > > On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann > wrote: > The only data point I have is that every time I've tried to disable DES in > a new release (and by DES I mean single DES, not 3DES) I've had a chorus of >

Re: [TLS] [Cfrg] 3DES diediedie

On Thu, Sep 8, 2016 at 8:01 AM, Derek Atkins wrote: > So they are finally up to 80-bit security? Woohoo! > That makes me feel so safe. > 1024-bit RSA is certainly less than ideal, but certainly better than nothing, which was the claim about devices in this class. Comparisons with symmetric cry

Re: [TLS] [Cfrg] 3DES diediedie

On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann wrote: > The only data point I have is that every time I've tried to disable DES in > a new release (and by DES I mean single DES, not 3DES) I've had a chorus of > complaints about it vanishing. ... > Alarms, for example, send data > quantities mea

Re: [TLS] [Cfrg] 3DES diediedie

Peter Gutmann writes: > Richard Hartmann writes: > >>Is it correct when I say that the embedded programmers you talked to don't >>care about any form of DES as they need/must/prefer to do AES, anyway? > > The only data point I have is that every time I've tried to disable DES in > a new release

Re: [TLS] [Cfrg] 3DES diediedie

Tony Arcieri writes: > On Tue, Sep 6, 2016 at 9:15 PM, Peter Gutmann > wrote: > > When crypto hardware support is available, it's universally AES, > occasionally > SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA  > > EMV chip cards support RSA digital signatures. Granted

Re: [TLS] [Cfrg] 3DES diediedie

Richard Hartmann writes: >Is it correct when I say that the embedded programmers you talked to don't >care about any form of DES as they need/must/prefer to do AES, anyway? The only data point I have is that every time I've tried to disable DES in a new release (and by DES I mean single DES, no

Re: [TLS] [Cfrg] 3DES diediedie

On Tue, Sep 6, 2016 at 9:15 PM, Peter Gutmann wrote: > When crypto hardware support is available, it's universally AES, > occasionally > SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA EMV chip cards support RSA digital signatures. Granted earlier EMV cards used ridiculously small

Re: [TLS] [Cfrg] 3DES diediedie

Perhaps a way forward here is for someone to document a target platform. Or multiple target platforms, and decide which are in-scope and out of scope for us to look at. Arguing by anecdote -- this lightbulb has this 10-cent part, that car has this ARM supercore with gigs of memory -- just gets

Re: [TLS] [Cfrg] 3DES diediedie

Ilari Liusvaara writes: >The TLS-style asymmetric designs don't come even close to cutting it if >client lacks good entropy source. Actually they're fine, see the comment about using entropy from both sides. You can run one side of a TLS communication with zero entropy (just a fixed secret) if y

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, Sep 7, 2016 at 6:15 AM, Peter Gutmann wrote: > [a lot of really interesting stuff] Thanks for the write-up. To focus what you wrote back on the thread at hand: Is it correct when I say that the embedded programmers you talked to don't care about any form of DES as they need/must/prefer t

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, Sep 07, 2016 at 04:15:05AM +, Peter Gutmann wrote: > Firmware is never updated, and frequently *can* never be updated. This is > typically because it's not writeable, or there's no room (the code already > occupies 120% of available storage, brought down to 100% by replacing the > cer

Re: [TLS] [Cfrg] 3DES diediedie

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Derek Atkins wrote: > Because this is a light bulb that sells for $6-10. Adding $2 to the > price is just completely unreasonable. The price point needs to be > pennies. Note that this is just one example, but yes, these level of > products

Re: [TLS] [Cfrg] 3DES diediedie

OK, so I said I'd get some notes on the environment within which IoT crypto has to function, here's what the peanut gallery came up with. A lot of this isn't my own work and I don't claim it to be, it's a collaboration created by people who for various business/legal reasons can't attach their nam

Re: [TLS] [Cfrg] 3DES diediedie

The market is moving to ARM Cortex Ms, in part because of their clean I/O architecture and good SoC support. An M0 with integrated BLE chipset is easily <1$ today at small scale. Extrapolate a few years and to volume of millions between large companies rather than small startups. Software like

Re: [TLS] [Cfrg] 3DES diediedie

Hi Dave, Might work for lightbulbs. Doesn't work for automotive sensors and ECUs, which already have proprietary security (undisclosed algorithms) and badly need to have standards-based security. Cents in cost really matter here. ARM CPUs are not and will not become the only answer in automotive

Re: [TLS] [Cfrg] 3DES diediedie

On Tuesday, September 06, 2016 04:40:30 pm Derek Atkins wrote: > Ben Laurie writes: > > An ARM is far too much hardware to throw at "read sensor/munge data/send > > data". > > > > The question is not "how much hardware?" but "price?" - with ARMs > > including h > > /w AES coming in at $2

Re: [TLS] [Cfrg] 3DES diediedie

Ben Laurie writes: > An ARM is far too much hardware to throw at "read sensor/munge data/send > data". > > The question is not "how much hardware?" but "price?" - with  ARMs including h > /w AES coming in at $2 for a single unit, its hard to explain why you\d want > to use a less powerful

Re: [TLS] [Cfrg] 3DES diediedie

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Hilarie Orman wrote: >> On 31 August 2016 at 20:48, Hilarie Orman >> wrote: > From: Brian Sniffen > >> The question is not "how much hardware?" but "price?" - with ARMs >> including h/w AES coming in at $2 for a single unit, its ha

Re: [TLS] [Cfrg] 3DES diediedie

On 5 September 2016 at 20:06, Hilarie Orman wrote: > At some time when attribution was hard, I wrote: > > On 31 August 2016 at 20:48, Hilarie Orman wrote: > > > An ARM is far too much hardware to throw at "read sensor/munge data/send > > > data". > > > The question is not "how much hardware?"

Re: [TLS] [Cfrg] 3DES diediedie

> On 31 August 2016 at 20:48, Hilarie Orman wrote: > > > From: Brian Sniffen > > > > > >> From: Derek Atkins > > > >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > > > > > > > >> "Steven M. Bellovin" writes: > > > > > > > >> > Yes. To a large extent, the "IoT devices are too pun

Re: [TLS] [Cfrg] 3DES diediedie

"Steven M. Bellovin" writes: > On 31 Aug 2016, at 10:17, Derek Atkins wrote: > >> "Steven M. Bellovin" writes: >> >>> Yes. To a large extent, the "IoT devices are too puny for real >>> crypto" is a hangover from several years ago. It was once true; for >>> the most part, it isn't today, but peo

Re: [TLS] [Cfrg] 3DES diediedie

On Mon, Aug 29, 2016 at 5:00 AM, Hubert Kario wrote: > > we have enough problems weeding out implementation mistakes in TLS, we > don't > need yet another protocol and two dozen implementations that come with it > Strongly agreed. Focusing energy on getting "something" working for low-power dev

Re: [TLS] [Cfrg] 3DES diediedie

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Hilarie Orman wrote: > For devices you refer to, how many AES blocks can they encrypt on a > AA battery, assuming that the usage is to encrypt one block every 10 > minutes? That is actually a very interesting, but hard question to answer. Wi

Re: [TLS] [Cfrg] 3DES diediedie

joac...@secworks.se writes: > Aloha! Aloha auinala. > Hilarie Orman wrote: > > An ARM is far too much hardware to throw at "read sensor/munge > > data/send data". > No, they are not. The Cortex M0+ is aimed at these kinds of very simple > systems that runs for many years on a single batte

Re: [TLS] [Cfrg] 3DES diediedie

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Hilarie Orman wrote: > An ARM is far too much hardware to throw at "read sensor/munge > data/send data". No, they are not. The Cortex M0+ is aimed at these kinds of very simple systems that runs for many years on a single battery. Look at t

Re: [TLS] [Cfrg] 3DES diediedie

On 31 Aug 2016, at 10:17, Derek Atkins wrote: > "Steven M. Bellovin" writes: > >> Yes. To a large extent, the "IoT devices are too puny for real >> crypto" is a hangover from several years ago. It was once true; for >> the most part, it isn't today, but people haven't flushed their cache >> from

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, August 31, 2016 3:48 pm, Hilarie Orman wrote: > > An ARM is far too much hardware to throw at "read sensor/munge data/send > data". What about an 8051? > Hilarie -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer

Re: [TLS] [Cfrg] 3DES diediedie

> From: Brian Sniffen > >> From: Derek Atkins > >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > > > >> "Steven M. Bellovin" writes: > > > >> > Yes. To a large extent, the "IoT devices are too puny for real > >> > crypto" is a hangover from several years ago. It was once true; for > >>

Re: [TLS] [Cfrg] 3DES diediedie

Hilarie Orman writes: >> From: Derek Atkins >> Date: Wed, 31 Aug 2016 10:17:25 -0400 > >> "Steven M. Bellovin" writes: > >> > Yes. To a large extent, the "IoT devices are too puny for real >> > crypto" is a hangover from several years ago. It was once true; for >> > the most part, it isn

Re: [TLS] [Cfrg] 3DES diediedie

> From: Derek Atkins > Date: Wed, 31 Aug 2016 10:17:25 -0400 > "Steven M. Bellovin" writes: > > Yes. To a large extent, the "IoT devices are too puny for real > > crypto" is a hangover from several years ago. It was once true; for > > the most part, it isn't today, but people haven't flu

Re: [TLS] [Cfrg] 3DES diediedie

"Steven M. Bellovin" writes: > Yes. To a large extent, the "IoT devices are too puny for real > crypto" is a hangover from several years ago. It was once true; for > the most part, it isn't today, but people haven't flushed their cache > from the old received wisdom. This is certainly true for

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) writes: >That’s great, facts leaven a debate. Yeah, but they also make it really boring, sigh. *Opinions*, now those are fun... Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

Hi Peter, On 8/30/16, 5:41 AM, "Peter Gutmann" wrote: >David McGrew (mcgrew) writes: > >>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 > >So looking at slide 6 fro

Re: [TLS] [Cfrg] 3DES diediedie

Jon Callas writes: >Current cryptographic standards work for IoT That's only if you use the circular argument that IoT is defined to be whatever can run DTLS (or whatever you take as "current cryptographic standards", the slides mention DTLS). An yeah, I can then define my IoT to be "whatever c

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) writes: >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 So looking at slide 6 from that, the first four systems he lists are desktop PCs (in all bu

Re: [TLS] [Cfrg] 3DES diediedie

On 29 Aug 2016, at 17:46, Jon Callas wrote: On Aug 29, 2016, at 5:44 AM, 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 in

Re: [TLS] [Cfrg] 3DES diediedie

> On Aug 29, 2016, at 5:44 AM, 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 Shu

Re: [TLS] [Cfrg] 3DES diediedie

On Mon, Aug 29, 2016 at 12:44:42PM +, David McGrew (mcgrew) wrote: > > 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. Yes, the variability of cap

Re: [TLS] [Cfrg] 3DES diediedie

Hi David and Peter, I think Daniels presentation is a good summary and I tend to agree with the “No lightweight cryptography in software”. But how relevant is lightweight cryptography in IoT hardware? I been hearing some hardware people stating that the number of gates is more and more irrelevant

Re: [TLS] [Cfrg] 3DES diediedie

-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

Re: [TLS] [Cfrg] 3DES diediedie

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/

Re: [TLS] [Cfrg] 3DES diediedie

On Sunday, 28 August 2016 13:55:47 CEST Peter Gutmann wrote: > Stephen Farrell writes: > >IIRC the IoT marketing term doesn't have a very long history so I don't > >really know what substance lies behind that remark. > > I just used "IoT" because someone else had used it, since it's about as > we

Re: [TLS] [Cfrg] 3DES diediedie

Stephen Farrell writes: >IIRC the IoT marketing term doesn't have a very long history so I don't >really know what substance lies behind that remark. I just used "IoT" because someone else had used it, since it's about as well- defined as "Web 2.0" I agree that it's not terribly useful to define

Re: [TLS] [Cfrg] 3DES diediedie

Peter, On 28/08/16 13:01, Peter Gutmann wrote: > David McGrew (mcgrew) 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 f

Re: [TLS] [Cfrg] 3DES diediedie

Karthikeyan Bhargavan writes: >If every message IoT device sends is a 16 bytes message consisting of one 8 >byte secret and one 8 byte known plaintext, then with a 64-bit cipher, we >only need roughly 64GB in order to get a meaningful collision (50% chance of >recovering the secret). The 768GB va

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) 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 be

Re: [TLS] [Cfrg] 3DES diediedie

> 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. I agree that it would be

Re: [TLS] [Cfrg] 3DES diediedie

Hi Peter, On 8/27/16, 8:21 AM, "Peter Gutmann" wrote: >David McGrew (mcgrew) 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

Re: [TLS] [Cfrg] 3DES diediedie

David McGrew (mcgrew) 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

Re: [TLS] [Cfrg] 3DES diediedie

On Fri, Aug 26, 2016 at 10:55 AM, David McGrew (mcgrew) wrote: > Hi Tony, > > Thanks for bringing this up; an RFC deprecating and/or discouraging 3DES > would be a good thing. The only good reason to use it is backwards > compatibility, and too many applications don’t heed the birthday bound. > >

Re: [TLS] [Cfrg] 3DES diediedie

Hi Tony, Thanks for bringing this up; an RFC deprecating and/or discouraging 3DES would be a good thing. The only good reason to use it is backwards compatibility, and too many applications don’t heed the birthday bound. There is another issue to be considered, though. Most of the lightweigh

Re: [TLS] [Cfrg] 3DES diediedie

Dear colleagues! I'd like to add that the described key meshing procedures (procedures to increase the lifetime of a key) are proven to be secure (and increasing security) in case of usage of CTR mode – see preprint at http://eprint.iacr.org/2016/628.pdf In case of CBC/CFB modes an additional sep

Re: [TLS] [Cfrg] 3DES diediedie

On Thursday, 25 August 2016 09:55:10 CEST Ira McDonald wrote: > Hi, > > This survey of TLS in 1 million web servers shows that 93% support 3DES - > oof! > > https://jve.linuxwall.info/blog/index.php?post/TLS_Survey > > 3DES hasn't quite disappeared on the Internet. but less than 0.5% will actua

Re: [TLS] [Cfrg] 3DES diediedie

Hi, This survey of TLS in 1 million web servers shows that 93% support 3DES - oof! https://jve.linuxwall.info/blog/index.php?post/TLS_Survey 3DES hasn't quite disappeared on the Internet. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG C

Re: [TLS] [Cfrg] 3DES diediedie

On Thu, Aug 25, 2016 at 6:21 AM, david wong wrote: > I don't think a RFC deprecating them is a good idea: > > * TLS 1.3 is almost here and is already doing that > * what browser still use 64-bit ciphers? Who lets his "old" browser open > for 75 hours? > Actually, I believe that all the major bro

Re: [TLS] [Cfrg] 3DES diediedie

I don't think a RFC deprecating them is a good idea: * TLS 1.3 is almost here and is already doing that * what browser still use 64-bit ciphers? Who lets his "old" browser open for 75 hours? * in other uses of TLS. It's not always obvious if there is a possible beast style attacks. And their imp

Re: [TLS] [Cfrg] 3DES diediedie

On Wednesday, 24 August 2016 22:59:23 CEST Viktor Dukhovni wrote: > I am not opposed to a "diediedie" RFC, if that is likely to be helpful. > For TLS, this ciphersuite is already comparatively rare, and perhaps its > disappearance will not be sped up by a "diediedie" RFC? Would an RFC > help to pr

Re: [TLS] [Cfrg] 3DES diediedie

On 25/08/16 10:54, John Mattsson wrote: > I think the recently published attack has more to do with bad > implementations/specification than a newly discovered weakness in 3DES. > That you should never encrypt anything near 2^32 blocks is well known (but > I don’t know how well this is explained

Re: [TLS] [Cfrg] 3DES diediedie

I think the recently published attack has more to do with bad implementations/specification than a newly discovered weakness in 3DES. That you should never encrypt anything near 2^32 blocks is well known (but I don’t know how well this is explained in NIST or IETF specifications, if at all). I am

Re: [TLS] [Cfrg] 3DES diediedie

> On Aug 24, 2016, at 10:34 PM, Tony Arcieri wrote: > > I am particularly interested in 3DES's usage in TLS, given its previous MTI > status in TLS, and because it was until very recently included in the OpenSSL > "DEFAULT" ciphersuite list. For the record, it is only removed from the "DEFAUL

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, Aug 24, 2016 at 7:41 PM, Stephen Farrell wrote: > On 25/08/16 03:34, Tony Arcieri wrote: > I guess there's sometimes value in those die-die-die RFCs. Given that > we have RFC7525/BCP195 [1] that already has a SHOULD NOT for effective > key sizes less than 128 bits, one could argue that th

Re: [TLS] [Cfrg] 3DES diediedie

On 25/08/16 03:34, Tony Arcieri wrote: > > https://sweet32.info/ Nice work. > On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk wrote: > >> Well, there is >> https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00 >> but it is not really what you are looking for, I think, give

Re: [TLS] [Cfrg] 3DES diediedie

It appears 3DES is not supported in TLS 1.3. I would still support a "diediedie" RFC banning its use in previous versions of TLS, despite its previous MTI status. On Wed, Aug 24, 2016 at 7:34 PM, Tony Arcieri wrote: > On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk wrote: > >> Well, there is >

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, Aug 24, 2016 at 7:31 PM, Benjamin Kaduk wrote: > Well, there is > https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00 > but it is not really what you are looking for, I think, given the > recipient list on the message. I am particularly interested in 3DES's usage i

Re: [TLS] [Cfrg] 3DES diediedie

On Wed, 24 Aug 2016, Tony Arcieri wrote: > This attack was published today[*]: > > https://sweet32.info/ > > I bring it up because I think the threat model is similar to the threats > that lead to RC4 "diediedie" > > https://www.rfc-editor.org/info/rfc7465 > > Should there be a 3DES "diediedie"?