On Sep 25, 2013, at 12:31 PM, ianG <i...@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 

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

The cryptography mailing list

Reply via email to