[cryptography] European report says many crypto protocols have problems

Nikos Fotiou nikosft at gmail.com
Mon Nov 4 05:09:16 EST 2013

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.


On Mon, Nov 4, 2013 at 11:39 AM, Paterson, Kenny
<Kenny.Paterson at 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" <pgut001 at cs.auckland.ac.nz> wrote:
>>Sandy Harris <sandyinchina at gmail.com> writes:
>>>Cited in a comment on Schneier's blog:
>>>Register article with link to actual report:
>>The original paper was written by some very smart cryptographers.  And
>>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
>>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
>>detail wrong.  Then it deprecates PKCS #1 v1.5 (which pretty much the
>>planet uses) because it doesn't have a security proof, while recommending
>>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
>>written by security engineers which makes recommendations on what's
>>in real life rather than on a whiteboard.  For example, we have several
>>billion SSL/TLS apps deployed (every PC, laptop, tablet, and smartphone
>>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 :-).
>>cryptography mailing list
>>cryptography at randombit.net
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography

More information about the cryptography mailing list