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
