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!"
who has probably has forgotten more about crypto than 99.9% of us will ever know
What's the margin of error on that figure?
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.
For an excellent treatment of this important point, that secrecy != security, read Bruce Schneier's "Secrets and Lies: Digital Security in a Networked World".
It's the best book on the topic available.
Arr! The laws of physics be a harsh mistress!
I just double ROT-13 everything for maximum protection. It seems to work so far. -- Note this message has been encrypted with double ROT-13 any attempts to understand it will in violation of the DMCA and will be duly noted.
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! (\(-__-)/)
Modest doubt is called the beacon of the wise. - William Shakespeare
... unless a woman enters the loop!
----- "Blame the guy who doesn't speak English." -- Homer J. Simpson
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.
One of his statements begs a question. Diffie says: "A secret that cannot be readily changed should be regarded as a vulnerability."
Yet asymmetric crypto (which I believe was publicised by Diffie and Helman (sp?) first) relies on one secret (the private key) being kept very very securely. Not only that, but if asymmetric crypto is to be any use, the secret should be kept for a fairly long time, as long as a signature needs to be valid. If you're going to use asymmetric crypto for legal purposes, to sign stuff, for instance, then the secret cannot be easily changed (unless there's some sort of central repository of keys that actually authenticates you properly when you ask to change your key, but even that is a bit dodgy).
Is it just me or does Diffie's statement, in a generalised form, kind of nullify the usefulness of asymmetric crypto? Or maybe I've missed the point...
Daniel
Carpe Diem
Also check out the "cryptogram" newsletters that Bruce Schneier writes at counterpane.com. He devotes some of the newsletter to discussing current events/topics and the security involved therein. Very interesting stuff.
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
On the whole, though, apart those 2 arguments, the article seems quite hollow imo, just your usual arguments on both sides... (NOT trying to start a flame war here, just expressing my opinion, to which of course you can disagree ^_-)
Tsuyoikoto ha taisetsu da ne, dakedo namida mo hitsuyousa (Strength is an important thing, but tears too are necessary)
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
"If you depend on a secret for your security, what do you do when the secret is discovered?"
Doh! That's obvious - Use the DCMA to sue their butts.
Perhaps its just me, but I'm reading between the lines that the issue really may not be Open Source vs. Commercial -- but who has the most to lose, in both intellectual property and in physical harm due to decryption by nere-do-wells.
I'm also seeing the same message over and over again, with this article, the book review previous to this article, and a few other articles that indicate that again, it comes down to human factors.
Again, the question becomes, how do we best secure the nut holding the keyboard?
--- have you healed your church website?
My IP is 127.0.0.1. Do your worst.
slashdot!=valid HTML
The code included a function specifically for a_times_b_mod_c using arbitrarily large numbers, and we used this function in the interest of speed. Unfortunately, there was a bug which caused the function to return a 0 result a little more often than expected (with C being "almost certainly" prime, it should almost never return a 0).
Fortunately, though, a 0 caused an error, rather than an insecure connection. When we got rid of the special function and instead used the overloaded * and % operators, everything worked fine.
I know there must have been more than a few eyeballs looking at the code in that function -- including mine -- but a potentially devastating bug snuck through. Heck, I didn't have a clue how that code was supposed to work. It was too mathematically complex for me.
The moral of the story? I suppose it's just this: the "many eyeballs" theory quickly breaks down in the face of esoteric algorithms.
Haha ... cute :)
For those of you who don't know, he's the co-inventor of public-key cryptography. Bow to him, because we're not worthy!
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.
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.
And he would tell us all about it if he had a mouth
Mouse powered Chips, Open source Processors and Lego
"This isn't a study in computer science, its a study in human behavior"
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.
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
.."Security through obscurity is no security"..
Can you explain what a password is if it isn't security through obscurity?
Consider a website that has on the front page a login box with the prompt "Admin Password:".
How is that any more secure than an "security through obscurity" approach, whereby the developer has made himself the following admin URL:
http://www.example.com/3458976394534/admin.html
Both the password, and the hidden URL are equally hard to guess. Yet people go on about how security through obscurity is no security.
Is anybody with me on this?
"If you depend on a secret for your security, what do you do when the secret is discovered? If it is easy to change, like a cryptographic key, you do so. If it's hard to change, like a cryptographic system or an operating system, you're stuck. You will be vulnerable until you invest the time and money to design another system."
The author has rightly pinpointed the pivotal dilemma of quite a many software designers. The problem is more about defining boundaries for modules handling security of the system. Do you integrate it strongly with the rest of the system? That creates a problem if a vulnerability is discovered and you have to invest more time and finances into taking care of all those 'integration points'. Do you design like a true pluggable module and let the system interact with it using few interfaces? That makes your whole system more transparent (some closed-source companies may whine here) and there may be possibilities of someone spoofing this external interface altogether. A balance is definitley required, but surprisingly most software designs seem to miss this point completely.
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.
Passwords can be changed, and can be changed quickly. If you discover a password has been compromised, locking down the system is a password change away.
If you want to be really secure, change your password daily. Or hourly. Or after each transaction.
But once your obfuscated URL is discovered - and discovering it is trivial - then the secret is out, and what little protection it did provide is lost until you can change the obfuscation.
For the best example, see the CSS system used on DVD players. That security system hinged on keeping something secret. Once it was discovered, there was no way to put the cat back in the bag without changing the key on everything that needed to be able to read DVDs - and obviously, the MPAA couldn't do that without rendering all the DVD players out there nonfunctional.
Secrets, as part of a security system, are BAD. They only become acceptable when they can be quickly changed once compromised. If they cannot be changed quickly, they render you more vulnerable than if they were out in the open to begin with.
DG
Want to learn about race cars? Read my Book
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!
It's the best book on the topic available.
Actually, I beg to differ. Security Engineering by Dr Ross Anderson is IMHO a far more rigorous treatment of this subject. Details are here. It's even just as easy to read as Schneiers book...Of course, Bruce is a far better at self marketting.
I am looking forward to getting Schneiers new Practical Cryptography book though (here).
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
To which I would add: I regularly check my brake fluids (and other stuff). However, most people I have seen who are not pilots don't even do a walk-around of their vehicles, they just jump in and go. Certainly I am not proposing each user become a "mechanic", but some basic training would go a long way.
This little penguin doesn't forget favors
If you qualify the statement as shared secret then it's pretty much correct. A private key (in a public/private pair) is never held by anyone other than the owner, nor is it necessary to transmit it in any way. And he can keep better track of it than anyone else can (or at least, he should).