Richard Hartmann <richih.mailingl...@gmail.com> 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, not 3DES) I've had a chorus of complaints about it vanishing. Unfortunately I don't have anything more than that, you only find out about things like this when they break stuff. Certainly DES still sees a surprising amount of use, and in many cases it's quite justified, whatever you're protecting is adequately safeguarded with DES. For example burglar alarms, if they use real encryption (far too many use "encryption" that would more accurately be described as data masking), often use DES, no doubt based on Microchip App Note 583 or freely available source like despiccable, which runs in 20 bytes of RAM (if your burglar alarm is advertised as having a "RISC based CPU" then it's probably using a PIC, having a processor so spartan it can barely add is now a marketing feature if you use the right name for it). They'll be using DES forever, because the entire environment they operate in runs DES. >If yes, there's no reason in the embedded world that would prevent a >diediedie. See above. You're not going to get rid of DES. And, as I've pointed out earlier, the embedded world won't even know your diediedie exists, and if it's pointed out to them they'll ignore it. Alarms, for example, send data quantities measured in bytes, so some academic attack that would take 500 million years to acquire the necessary data isn't going to lose anyone any sleep. It's a nice piece of work, but you need to look at what practical effect it has on real, deployed systems... Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
