Remember - did at least 3 of these, 20 years ago. :) Still true - still valid - still good advice. I avoid the scratching, but maybe also this helps. --Michael
Am 27.09.2013 um 14:47 schrieb John Young <[email protected]>: > 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 > >
