Peter, (Full disclosure: I was one of the external reviewers of this report.)
I take your point that there is a gap between cryptography and security engineering, and I understand the gap well from first-hand experience, first from my time in industry and more recently as a consultant to industry. You are quite right that PKCS#1v1.5 is very widely used and widely supported in developer libraries. But that does not mean it should continue to be used forever, especially in view of the fact that it has been repeatedly broken (in a practical sense) in different application scenarios. Let me know if you want the list of papers showing this - but you could start by re-reading Bleichenbacher's "million message attack" paper from Crypto 1998, and then the more recent paper by Bardou et al. from Crypto 2012 (slides here: http://www.iacr.org/conferences/crypto2012/slides/11-1-Steel.pdf). PKCS#1v1.5 makes a great example of why theoretical weaknesses should not be ignored: attacks that start off that way generally only get stronger with time. So what are we to do? Continue to recommend something that is cryptographically dreadful simply because everybody is using it? Or to try to kickstart the process of breaking with the past? My view is that the latter is the right course of action. And a report like this is an opportunity to do so. It provides a lever for crypto engineers to start pushing for more cryptographically robust solutions. You mention SSL/TLS and the billions of devices and apps using it. Interesting case study. By your argument, we should continue to use RC4 or MAC-then-encrypt in that protocol, since, hey, everybody is using them, they are good enough, and we can patch against the currently known attacks. Interesting exercise in double-think to try to reconcile that with your proposals over on the TLS mailing list (specifically draft-gutmann-tls-encrypt-then-mac-00.txt). What gives? By the way, I think you should write your proposed report. Or lobby for some body like ENISA to commission it. Cheers Kenny On 04/11/2013 00:40, "Peter Gutmann" <[email protected]> wrote: >Sandy Harris <[email protected]> writes: > >>Cited in a comment on Schneier's blog: >>https://www.schneier.com/blog/archives/2013/10/nsa_eavesdroppi_2.html >> >>Register article with link to actual report: >>http://www.theregister.co.uk/2013/10/31/most_security_protocols_insecure_ >>suggests_enisa/ > >The original paper was written by some very smart cryptographers. And >that's >the problem, it was written by cryptographers, not security engineers. >If I >wanted to run crypto on a whiteboard, I'd definitely follow the >recommendations in the paper. However, looking at systems deployed in >practice... well, I'll refer people to the Crypto Gardening Guide and >Planting >Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, and in >particular Questions I and J and the Final Thoughts. > >Beyond that, there are other problems with the recommendation. For >example it >strongly recommends DLP algorithms over RSA. DLP is great on a >whiteboard but >extremely brittle in practice, since the entire family has a distressing >propensity to leak the private key if you get even the tiniest >implementation >detail wrong. Then it deprecates PKCS #1 v1.5 (which pretty much the >entire >planet uses) because it doesn't have a security proof, while recommending >a >bunch of exotic alternatives that more or less nothing uses. > >So what I'd be interested in seeing in response to this report is another >one >written by security engineers which makes recommendations on what's >practical >in real life rather than on a whiteboard. For example, we have several >billion SSL/TLS apps deployed (every PC, laptop, tablet, and smartphone >has >one, not to mention any number of embdded devices, the figure "several >billion" is not an exaggeration), how should we configure those to >provide the >best security possible? > >(NB: I am not volunteering to write this report :-). > >Peter. >_______________________________________________ >cryptography mailing list >[email protected] >http://lists.randombit.net/mailman/listinfo/cryptography > _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
