Ask Slashdot: Can Bruce Schneier Be Trusted? 330
An anonymous reader writes "Security guru Bruce Schneier is, among other things, a world renowned cryptography expert, author of several popular books, and a second-order internet meme. He is also an outspoken critic of the NSA, in particular the massive NSA surveillance programs disclosed over the summer by Edward Snowden. Schneier has been involved in reviewing the leaked documents and has put in effort to determine which cryptosystems should still be considered safe. I'm a big fan of Bruce Schneier, but just to play devil's advocate, let's say, hypothetically, that Schneier is actually in cahoots with the NSA. Who better to reinstate public trust in weakened cryptosystems? As an exercise in security that Schneier himself may find interesting, what methods are available for proving (or at least affirming) that we can trust Bruce Schneier?"
Oh please (Score:4, Informative)
If we can't trust old Bruce, we're all screwed. Though possibly we are anyway. But if he's an asset, he's pretty well disguised.
Re:Just double the encryption (Score:4, Informative)
This is why we need a "+2 insightful AND funny" category, dammit.
Re:Trust no one (Score:5, Informative)
"Even the compiler can be compromised. Ken Thompson showed that."
Well, double compiling techniques can be used to certify a compiler. (Though it actually assume that you have access to an other safe compiler, which is a little bit complicated, but doable)
http://arxiv.org/abs/1004.5534 [arxiv.org]
Re: Learn math (Score:5, Informative)
You know he's designed several ciphers, right? Blowfish, Twofish, perhaps you've heard of them? Twofish was an AES finalist. If that doesn't give him credentials, what does?
Re:Trust no one (Score:4, Informative)
You have to trust someone, somewhere along the line.
The open source movement (Down people! It's just an umbrella term, not an excuse to rage about the nuaned differences in licensing) recognized early on that the only way to create reasonably secure code is to publish it and let anyone look at it. Politics demands that for every group of people out there wanting power for a specific purpose, there's another group willing to sabotage them. As long as the code is a black box, the war between those groups will be won and fought or lost without anyone being the wiser -- unless the code is published.
Then, regardless of individual motive, you're on one of either two sides: Publish or don't. If you publish, there's a big risk of being identified if you try anything and in covert operations anonymity is better than bulletproof armor. Nobody's going to risk having their real identity linked to a subversion attempt. So that leaves not publishing -- keeping potential exploits to yourself. This is what the NSA and other intelligence communities are doing.
When you play that game, however, you're stuck in an arms race where every participant is fighting a war on two fronts -- they can exploit the holes in the enemy's systems, but because the enemy uses a lot of the same technology, they can turn around and do the same to you... which means every weapon is 'single use' against hard targets. But I guess that's how the NSA likes it; As long as you have tons of money to waste, those with the most gold have the most power. It's direct proportionality.
Actively maintained open source though allows people to build reasonably secure systems without a big investment -- anyone can incrementally improve it. So if you aren't the NSA (ie, second place and below)... it makes sense to contribute to projects like Linux and build your security around them. The NSA has been 'caught' (as much as anyone can be caught in cyberwarfare -- attributation is a bitch, anyone who has researched it knows this) several times trying and failing to create exploits in Linux. This tells me that the cost of finding a linux exploit is now at least equal to that of its closed-source competitors, and may even be higher -- otherwise why risk exposure?
Any once you find a linux exploit, you're still on the clock -- this isn't like closed source. New people are constantly looking at code, even old code, and could discover your hard-won exploit and close it. Basically, if you're not a "top 10" government and you want security... use open source.
Re:Diverse Double-Compiling (trust but verify) (Score:5, Informative)
I've gotten a lot of hits, and that's a good thing. As I noted in another post [dwheeler.com], I got hit by reddit [reddit.com] earlier this year. In general people are becoming more interested in protecting and verifying build environments, as this post about Tor demonstrates [torproject.org].
So please take a look at my Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) [dwheeler.com] page!
Bruce Schneier connection (Score:4, Informative)
Oh, and a Bruce Schneier connection: In 2006 Bruce wrote a summary of my ACSAC paper on diverse double-compiling (DDC). Bruce's article is simply titled Countering "Trusting Trust" [schneier.com].
Bruce completely understood the approach. He explained it very well in his blog, and he also did a nice job explaining its larger ramifications. His conclusions are still true: the "trusting trust" attack has actually gotten easier over time, because compilers have gotten increasingly complex, giving attackers more places to hide their attacks. Here's how you can use a simpler compiler -- that you can trust more -- to act as a watchdog on the more sophisticated and more complex compiler.
Re:Trust no one (Score:5, Informative)
That's a huge jump, and a red flag for a shitty argument. As you wrote it, yes it is misguided. You don't have to make a significant contribution, just understand what's already out there. And it's way more than "a little math".
Yes. That was simple, wasn't it?
Actually, no. Simply understanding the mathematics will not make it clear. Understanding the math, then having it pointed out, or reading Bleichenbacher's paper, will make it clear. But merely learning the math will not... else it wouldn't have taken decades for someone to discover that problem.
The MD5 collision was an algorithm based on math.
No, it wasn't/isn't. MD5, like all modern hash functions, are based on repeated mixing. It can be modeled mathematically, but it's not "based" on math in any meaningful sense.
But the basic statistical analyses which show whether something may be vulnerable, is all math.
Yes, statistics is math. Do the stats for me and tell me if SHA-256 is vulnerable, would you?
The math for AES can be found on the wikipedia.
The algorithm can. Block ciphers aren't really based in any meaningful sense on mathematics either. Mathematical tools are used to model them and look for weaknesses... but there's also a healthy dose of good "intuition" that goes into cipher design.
The current choices for Dual ECC were proven suspect by math.
Partly. The concern derives as much from observation of process as from the math.
The advice is not laughable in context- trust no one. And, it's not impossible to learn this stuff, you can either choose to or choose not to.
I've spent a big part of the last 20+ years learning it (among other things; I'm not a researcher and crypto is only part of my job), and I work with a bunch of other people who've devoted their whole lives to it. And you know what? If you ask them if anything is good, they'll immediately start looking for research papers to find out... because there is no realistic option but to trust the work that others have done, and which has been peer reviewed and vetted.
Don't trust the researchers - verify it yourself. That's not original research, it's just common sense (for the paranoid).
That's not what the researchers do. But you're smarter and more paranoid than they are. Gotcha.