By no means I claim to be an expert, but what I feel is that ENISA's report is missing recommendations for TLS key exchange algorithms. I would except this report to recommend algorithms that achieve forward secrecy. In any case I found the report very comprehensive and well suited for an engineer.
Best, Nikos On Mon, Nov 4, 2013 at 11:39 AM, Paterson, Kenny <kenny.pater...@rhul.ac.uk> wrote: > 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" <pgut...@cs.auckland.ac.nz> wrote: > >>Sandy Harris <sandyinch...@gmail.com> 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 >>cryptography@randombit.net >>http://lists.randombit.net/mailman/listinfo/cryptography >> > > > _______________________________________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
