There was a time when non-official crypto wizards recommended:
From best to worst:
1. Roll your own, keep it quiet, change it often, monetize as a
last resort before a cheated partner cuts your throat.
2. Avoid commercial giants most inevitably in bed with officials
to screw users mercilessly laughing on the way to SWIFT.
3. Avoid products of the most powerful nations and their satellites
and gangsters bypassing export controls in service to those
very nations' covert armaments-economic policies.
4. Avoid any widely touted, admired, promoted as the best due
to long history of dupery by this magic bullet.
5. Use off-market, black market, deep web, blacknet, onionized,
layered, piggy-backed, scatalogically provened reliable based
on total avoidance of the many hegemons working the cypto
fleece terrain, expect to be reamed, dosed and sausaged.
6. Go back to No. 1, repeat, daily, hourly, minutely, pause,
wonder is this nuts, pound delete, backspace, esc, ctrl-alt-del,
smash the EENT device.
7. Pick nose, ear, tooth, scratch crotch, hmm, scratch some
more, log onto revenge porn, spot your ex-partner leaking
your perfect privacy prophylactic.
At 08:09 AM 9/27/2013, you wrote:
----- Forwarded message from Jerry Leichter <[email protected]> -----
Date: Wed, 25 Sep 2013 14:12:25 -0400
From: Jerry Leichter <[email protected]>
To: ianG <[email protected]>
Cc: [email protected]
Subject: Re: [Cryptography] RSA recommends against use of its own products.
X-Mailer: Apple Mail (2.1510)
On Sep 25, 2013, at 12:31 PM, ianG <[email protected]> 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
_______________________________________________
The cryptography mailing list
[email protected]
http://www.metzdowd.com/mailman/listinfo/cryptography
----- End forwarded message -----
--
Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
