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!"
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
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
It is known that 84.2% of people make up percentages on the spot... I would bet that the rest use outdated data (e.g. older than 1 second).
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
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
So that must mean that most slashdotters are the most secure people on the planet.
"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.
You have never ever seen a woman, you never will
Then what the hell was it that put a gold band on my ring finger??? Now I'm scared to go home, thanks alot.
----- "Blame the guy who doesn't speak English." -- Homer J. Simpson
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.
"This isn't a study in computer science, its a study in human behavior"
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.
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."
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.
/.?
Then you must not get out much.
Alexis de Tocqueville Institution published a white paper (funded by Microsoft) that argues this very point. Do you consider them "slashdot trolls"?
How about Steve Lipner, manager of Microsoft's security response center? Is he a troll too?
Hmm, ZDNet has another (unnamed this time) source from MS, who claims that too. You're saying that MS's spokespeople troll
I've also seen company websites (SoftArc comes immediatly to mind) that stated (in effect) "we don't release source code because it's more secure that way" - sorry, no link for this one, as they've changed their site... but there is a chice quote on their security page, where they explain that their products are more secure because "connections employ entirely proprietary protocols"
The thing is that this FUD is spewed about by people who don't know what they're talking about, and believed by others who haven't thought about it too much. "Security through obscurity" makes an inutitive kind of common sense, unless you think about it for awhile, or are exposed to the flaws (which aren't as intuitive.) It's the same kind of sense that got the DMCA passed.
Mr. Diffie isn't writing for the security community, but for the people outside the security community, who might be led to believe that obscurity does provide security.
Can you explain what a password is if it isn't security through obscurity?
*sigh* I hear this all the time, and it's fundamentally flawed logic.
Obscurity is keeping something a secret that could be found out by some other means.
A password is a method of authentication - you prove you are authorized to do something because of something you know.
A properly administered password is not obscurity because the only way to get it is for someone who is authorized to tell you explicitly.
A password is *not* obscurity - unless you store your passwords in a publically accessible place, and think that "nobody will think to look there."
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.
And this is the perfect example of what I'm talking about.
They are equally hard to guess, but there is a _huge_ difference between the URL and the password in your example, because the URL can show up in other places (like, say, referrer logs!) if you link to _anything_ in that page that you don't have 100% control over, your URL will leak to the outside world, and your server is compromised.
Or what about a browser cache? Or URL history? Both methods will make your URL "security" method useless.
And what if someone looks over your shoulder at the screen? The URL is printed in plain text right in the browsers address bar.
Well, the problem is that more and more people keep showing up, despite the man with the machine gun.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant