Slashdot Mirror
Decrypting the Secret to Strong Security
farrellj writes "Cnet has an excellent article by Whitfield Diffie, who has probably has forgotten more about crypto than 99.9% of us will ever know, explains why secrecy does not equal security. The article also addresses the whole "open source vs proprietary software" security issue. A definite *must read* for anyone concerned about security...and that should be everyone!"
To me, that says that making sure the programs used for a company's network security or documents or whatever actually work and protect the network. Too bad it seems that a lot of companies lack the protection that is supposed to be a "natural function" of the company's network/data security personnel.
Ah am not a crook! (\(-__-)/)
Whilst not quite in the random eye meaning of the article.
OSS does need proper audit and change tracking.
I've looked thorough quite a bit of OSS, and I've fixed a few bugs,
But apart from a patch there's no real way to track what code I thought needed atention, what was good and what was a mess.
Patches are good for tracking maturity/stability if used well, a section of the code that hasn't been patched for a while is either very stable or needs looking at.
thank God the internet isn't a human right.
Diffie is definitely the guy to be talking about this. Considering a main form of private key-exchange is called Diffie-Hellman.
But, nontheless, it's silly that people don't know this inherently. A secure system is only as secure as its weakest point. If that point is compromised and cannot be easily fixed and/or repaired. It's useless.
Depending on the secrecy of the code or "Security through Obscurity" is useless. Anyone who tells you otherwise is a quack or is trying to sell you something and doesn't want to do all the work necessary to do the proper job.
If you want a secure system, you have to instantly assume that the system, code, and key will eventually be completely compromised, and then you can begin to think about. Now, if any of these were compromised, how can I fix the problem. The current solution is to reset the keys, and using modern mathematics (most of which was developed by Dif) You can do this securely.
Now, the only problem that remains with modern cryptography, is if the factoring problem is solved _and_ the elliptic curve problem is solved efficiently, then modern crypto becomes useless, and we are back to square one.
Albeit, Quantum Cryptography has some potential as it provides a mathematically verifiable form of perfect cryptography, since it is one time pads. It just currently cannot be done over long enough distances to be completely effective. When the technical/engineering details are solved for QC, then crypto is guaranteed secure. Assuming no one compromises your system directly (Human Error).
Dependence on Security through Obscurity is bad, incredibly bad, and I hope anyone programming security software out there will realize that, and begin to use proper cryptographic techniques.
** I am going to write a couple of journal articles soon reviewing the various techniques for those who are interested. **
~ kjrose
That may be an excellent article for someone who has never been told that secrecy != security, but he didn't really say anything new. He didn't even really support any of his points. It isn't even really an article, more like a blurb. It's like someone at CNET said, "Give us 1,000 words on why OSS is good."
Si vis pacem, para bellum
The only thing more annoying than a Libertarian is an (un|mis)informed Libertarian
I haven't seen anyone (save a few Slashdot trolls) seriously argue that binary-only software is inherently more secure, either in theory or in practice. So at first it sounds like Mr Diffie is setting up a straw man at the beginning of his article. But then you realize that the 'opponents' are not serious arguments but, on the whole, vague FUD wafting about that may be swallowed by less-technical people. So his article is an attempt to explain to the rest of the world what the security industry already knew.
-- Ed Avis ed@membled.com
But of course, physical security won't help at all if the company has a wireless network ...
yes, another good point. Which simply stresses the importance of taking a, uh, holistic approach to security and to not to get too wrapped up in just a single aspect. We've all been in companies where they spend good money trying to secure their systems against "crackers" but yet anyone in the company has access to the server boxes and/or the passwords are written on the side of the monitors, etc.
If microsoft opened up their all their software tonight. Tomorrow morning every windows server would be down, every internet-connected desktop would be down, Infact anything that could be down would be down. Open source software such as linux is probably on a higher level than closed source, so the majority of bugs that could be found in linux already have. For example, if you open fire randomly at a crowd with a machine gun, you'll hit more people in the first few seconds than in the next minute, because after you've taken out the bulk, what your left with is afew scattered people that are harder to pick off - anyone who plays fps's will know what i mean.
This comment does not represent the views or opinions of the user.
Anything that helps convince my crypto-less clients to use GnuPG is very, very helpful.
Never attribute to malice that which can be explained by mere idiocy.
I forget who said this, but there's a real paradox with security that the more you THINK you have, the more risks you will take, and therefore the less safe you are. When you know you are vulnerable, it heightens the senses, focuses your awareness. You're sharper, because you have to be.
I'm not saying throw the security away, but think about this: trusting on a secret can make you complacent just as Diffie writes. Knowing your code is Open Source and everyone can look at it should help you focus on the real problem, which is that security is a moving target and needs constant evaluation.
I agree with WD's theme, but his defense of Open Source has a weak/irrelevant point.
I think auto-manufacturer responsibility is anchored in legal liability. If the wheels come off, the builder is sued, no matter whether the engineering diagrams are freely available to the car's owner.
Yes, but it doesn't mean someone is. He's arguing in favour of a (legally liable) vendor.
As noted by other posters, the basic arguments have been written in more detail by people like Bruce Schneier -- see his Cryptogram newsletters for some well-thought-out writing.
A nice little article, suitable for sharing with less-technical coworkers.
je ne suis pas un fou
OSS can be viewed by many eyes.
... but security in the OSS world has yet to be proven.
But is it?
Can you be sure that each and every code change is reviewed by competent individuals trained and experienced in security and with a comprehensive knowledge of the architectural issues with the work product? By each and every we include device drivers from every source under the sun that are in the kernel and thus have the ability to do good things or ill.
Who maintains the security model, the design documents, the overall architecture? Who argues that this code, while it speeds things up wonderfully, violates architectural principles that are important to the security of the entire system? And who can make the decision stick...that security is more important than functionality or speed.
Yes OSS could be more secure than most proprietary products by virtue of the quantity of eyes.
But perhaps it is possible to make a product even more secure by following great developmental practices, ones that are only enforceable in a proprietary world. And submitting it to peer review by acknowledged experts.
Compare the assurance requirements contained within the Common Criteria to the practices followed in most OSS product development and maintenance. OSS has some real problems.
Not that it isn't wonderful
For someone who is supposed to be an utmost authority in crypto...his article was very lacking in anything that remotely addressed the issue of the question at the heading 'Is open-source software better for security than proprietary software?'
It addressed secrecy as a form of security...proprietary software is NOT secrect software.
I just feel that someone with his credentials should have been able to come up with some arguement or form of support. All in all I wouldn't recommend the article to be read at all, for it lacks any insight on the topic it was supposed to address.
"Just Smile and Nod." --Huck
Passwords can be seen as a secret used for security. The author also mentions cryptographic keys in the same context. He justifies them by saying that because they can be easily changed, they aren't a great detriment to security. I'm not sure I agree. In the past, the most common way to gain unauthorized access to a machine was through weak passwords. And even if you have a strong password, it may be difficult to know if it becomes compromised.
I've always wished for a system like RSA'a SecurID cards. They give you a password that changes every 60 seconds, and you carry around a token that shows the latest password for you. Unfortunately, such technology is priced out of the range of individuals like me.
For every post, there is an equal and opposite re-post.
The moral of the story? I suppose it's just this: 'the "many eyeballs" theory quickly breaks down in the face of esoteric algorithms'.
But.. but...
You found the bug, and now the world at large knows about it. You are a living example of the "many eyeballs" theory in action. You don't *have* to spot the bug merely by eyeballing the code; witnessing it in the wild counts too.
I have to disagree. Secrets and Lies is a great book because it is not technical. It presents clearly the problems and challenges associated with securing a system, and then discusses means to solve the problems and overcome the challenges. It makes you realize that security must be an integral part of a system, not a bolted-on afterthought.
In discussing these things in a non-technical manner, Schneier gets you (as a developer) to stop thinking about which trendy algorithm or PKI you're going to tack on to your product to call it secure, and start thinking about the security of the system itself. So you use cryptography; so what? What's the point in encrypting your data if you don't also ensure its authenticity and origin? You're using PKI to secure communications; so what? Are you also ensuring the security and integrity of the keys' local storage? Security is a process, not a product, and the biggest problem with purely technical books on cryptography or security (they're not the same thing) is that they give the impression that you can sprinkle their code samples throughout your project and have it be magically secure.
It's a bit like me reading a book on security and declaring myself an expert because I read a book on security. Knowledge != understanding.
Arr! The laws of physics be a harsh mistress!
or maybe they just pay him really really good. and have a nice vacation plan.
No, the moral of the story is that you found the error and corrected it, thus solving the problem. Could you have fixed it if you didn't have the source?
Programmers and designers make mistakes. Programmers and designers will probably always make mistakes. The real issue is how do you find and fix the errors, whether they are based in the code or the algorithm or in the application logic. If you can't see the source, that's just one more obstacle in the way, one more source of noise to work through.
What happened instead was, as soon as consumers heard about the vulnerability, they had the option of patching it themselves, namely, going to Tires-R-Us and getting a new set of tires. The argument was not "study => security" but "secrecy != security" and "easy fix => security"
EnkiduEOT
There is no trap so deadly as the trap you set for yourself
-Raymond Chandler, The Long Goodbye