[Cryptography] RSA recommends against use of its own products.

[Jerry Leichter]

On Sep 25, 2013, at 12:31 PM, ianG <iang at iang.org> wrote:

> Hi Jerry,
> 
> I appreciate the devil's advocate approach here, it has helped to get my thoughts in order!  Thanks!
:-)

> My conclusion is:  avoid all USA, Inc, providers of cryptographic products.
In favor off ... who?

We already know that GCHQ is at least as heavily into this monitoring business as NSA, so British providers are out.  The French have been playing the "oh, we're shocked, shocked that there's spying going on" game - but they have a long history of their own.  It's been reported for many years that all Air France seats are bugged by the French security services and the information recorded has been used to help French economic interests.  And even if you don't think a particular security service has been going after in-country suppliers, recall decades of US spiking of the Swiss Crypto AG machines.

It's a really, really difficult problem.  For deterministic algorithms, in principle, you can sandbox the implementation (both physically and in software) and compare inputs and outputs to a specification.  That leaves you to worry about (a) holes in the specification itself; (b) physical leakage of extra information (Tempest-like).  Both of these can be dealt with and you can gain any degree of assurance you consider necessary, at least in principle.  Sure, someone can spike your hardware - but if it only does what the spec says it's supposed to do, what does that gain them?  (Storing some of your secrets within the sandboxed system does them no good if they can't get the information out.  Of course, physical security is essential, or your attacker will just walk the system, with all its contained information, out the door!)

For probabilistic algorithms - choosing a random number is, of course, the simplest example - it's much, much harder.  You're pretty much forced to rely on some mathematics and other analysis - testing can't help you much.

There are really no absolutes; you really have to think about who you want to protect yourself from and how much you are willing to spend, because there's no limit on how much you *could* do.  Build your own foundry?  Create your own circuit synthesis code?  You very quickly get yourself into a domain where only a handful of companies or countries can even begin to go.

My take on this:  I don't much worry about attacks against general-purpose hardware.  The difficulty of modifying a processor so that you can tell when it's implementing a cipher and then do something useful about it seems insurmountable.  The exception is when the hardware actually gets into the crypto game - e.g., the Intel AES extensions and the random number generator.  If you're going to use these, you need to do so in a way that's secure even if those features are spiked - e.g., use the random number generator only as one of a couple of sources.

Still, *much* more worrisome are the badly implemented, insecure extensions to allow remote control of the hardware, which are being discussed in a separate thread here.  These are really scary - there's no protection against an attacker who can send a magic packet to your network interface and execute code with full privileges.

Code, at least for symmetric cryptography primitives and modes, is simple enough that you can find it all over the place.  Realistically, the worst attacks against implementations these days are timing attacks.  Bernstein's ciphers have the advantage of being inherently secure against these, showing that this is possible (even if you don't necessarily trust his particular constructions).

Denker's ideas about how to get random numbers whose safety is based on physical principles are great.  You do have to be careful of the hardware and software you use, but since the hardware is designed for entirely different purposes (A/D sound converters) it's unlikely anyone has, or really could, spike them all.

It's the asymmetric algorithms and implementations that seem to be the most vulnerable.  They are complex and difficult to get right, much less to get both efficient *and* right, and protocols that use them generally need to be probabilistic - so "black box testing" isn't feasible.  At the same time, they have rich mathematical structures in which we know things can be hidden.  (In the symmetric case, the algorithms are generally have little mathematical structure, and we *assume* nothing can be hidden in there - but who can really say with absolute confidence.)  I had a long debate here earlier on this subject, and my own conclusions remain:  Use symmetric crypto as little as you possibly can.  (What would be really, really nice is something like DH key exchange without all the mathematical structure.)

                                                        -- Jerry