[cryptography] European report says many crypto protocols have problems

Paterson, Kenny Kenny.Paterson at rhul.ac.uk
Mon Nov 4 04:39:03 EST 2013


(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

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:
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.



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

More information about the cryptography mailing list