"Paterson, Kenny" <kenny.pater...@rhul.ac.uk> writes: >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.
It's actually a much messier combination of both options. Let's say someone decides to follow the report's recommendations for some sort of secure-session protocol. So they use all the good mechanisms and come up with their own version of TLS. Unless their name happens to be Shamir or something along those lines, chances are they're going to reinvent TLS badly. So the choice will be between a set of non-best-practice algorithms in a protocol that's had two decades of analysis and for which we have a pretty good idea of what, and what not, to do, and a set of best-practice algorithms in a new and/or homebrew protocol that could well fall over the first time anyone looks at it. I would love to design a better TLS (as would any security person, it'd be like letting a kid loose in a room full of lego), but (a) I'm not at all confident I'd get it right compared to 20 years of TLS analysis by the global cryto/security community, and (b) I wouldn't have a hope of getting it adopted even if I did. >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. I'm arguing for incremental upgrades to existing protocols, not greenfields developments. It's probably too late to invent a "better TLS" or "better PGP" or "better S/MIME" now (although we can always do a better IPsec :-), so we have to incrementally upgrade existing universal-substrate protocols as best we can. >By the way, I think you should write your proposed report. Or lobby for some >body like ENISA to commission it. First I'd like to have something like a roundtable or panel session between the security engineers and the cryptographers to hammer out what is and isn't feasible. Can you make it to Kiwicon in Wellington, New Zealand, by Friday? :-). Peter. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
