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!
You missed the point...
Everybody can know the RSA algorithm, it's no secret. If everybody knows the code then the "good guys" and the "bad guys" can look at it. So, if in all this years nobody from the "good guys" found a flaw in it, it means that almost by sure it is safe.
Now image a crypto algorithm that is kept secrept. There are less eyes looking at it. The "good guys" don't waste much time reverse-engineering it, but the "bad guys" do. So the probability of a "bad guy" finding a flaw before the "good guys" is much bigger.
The secret is in the key, not the algorithm. Keys are easially changed, algorithms no
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!
Quantum cryptography solves one specific problem: to share (or, strictly speaking, expand) a secret over a distance. This secret can be a one-time pad.
However, sharing a secret over a distance is just one building block of a cryptosystem. There are many others it doesn't help with, e.g. sharing an initial key, or digital signatures.
I don't think it's quite that bad. Imagine you are maintaining a repository of signed documents (eg security patches for an OS). You sign these with a private key and make sur ethe public key is widely advertised, so people can check that your documents have not been compromised.
Now, assume your private key is compromised. This is bad but not the end of civilisation as we know it. You can make sure the world knows not to trust that key, at which point is as if your repository had never existed, and you are starting from scratch. You would need to get your documents back from a trusted archive (you did take backups didn't you:-)), and sign them with a new key pair. You are back in busines as soon as the new public key had been recieved and verified by enough trustworthy people.
So, loss of the secret is a big pain in the arse, but not disasterous. Just how painful it is depends on how well you have planned, eg having that trusted archive, having channels to quickly disavow your compromised key and the network of widely trusted people who know how to check that your new key really came from you.
in a legally signed document scenario, you might arange for an electronic notary to annotate your document with the date you signed it and then sign the annoted document. Then people could tell whether the document was signed before your key was compromised, and a fraudster needs to get at both your secret and that of the notary.
_O_
.|< The named which can be named is not the true named
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.
http://www.example.com/3458976394534/admin.html
:) Google might spider a site with public proxy logs, and it gets in that way.
:)
Yeah - and just wait until that gets into Google
Wait, that's given me an idea....
Get your own free personal location tracker
The RSA problem is reduceable to the factoring problem.
The discrete logarithm problem is related to the diffie-hellman key exchange.
Almost all of these problems though reduce to a simple NP problem, in which case, if one is possible to do efficiently, they'll all be likely solved.
~ kjrose
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).
Diffie-Hellman key exchange relies on two secrets between the two people who are communicating (or three for three people, and so on), and these secrets are nothing but large, random integers. Since these integers don't have to have any specific properties (such as the key pairs in RSA) they can be thrown away at the end of the session, changed every hour, and so on. In the context of cryptographic algorithms, Diffie's statement is backed up by his inventions.
See: http://www.apocalypse.org/pub/u/seven/diffie.html
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.
Yes and no.
Kerck hoff's Law is certainly the starting point, and extending that to consider the system's reaction to key compromise is an essential step, but in the real world things are... messier.
In some cases, for example, it is impossible (or at least not cost-effective) to correct the security defects in a deployed system, and in these cases obscurity is a good choice.
For example: Consider a smart card system used for reloadable electronic cash transactions. There may be many millions of cards in circulation, and the security of the system as a whole relies to some extent on the ability of each card to keep its keys secret and to perform its operations correctly. Now suppose that the software on this smart card chip contains a defect which will permit an attacker to violate these security assumptions.
Is it better, for security, to publish the source code or to keep it secret? I maintain that it's better, under real-world assumptions, to keep it secret. Why?
First, recognize that publishing the code makes it *more* likely that the defect will be discovered. An attacker has a steep uphill climb to discover a defect in this particular code, since he first has to peel apart layers of metal cladding and silicon to get to the ROM to read the object code out of the transistors (and it's designed to make this as difficult as possible) before he can even begin to analyze it. Black box bug-hunting is extremely difficult as well, since the software is paranoid and a few failed transactions will cause it to refuse to operate any more. Keeping the code secret prevents all but the most determined attackers from even looking for holes, much less finding them.
Second, keep in mind that if a defect is discovered, "fixing" the hole is a very, very expensive proposition. All of those millions of cards must be replaced. If the source is open, the fact that "white hats" have discovered the defect means that it must be assumed that "black hats" have as well. If the source is carefully protected, the fact that finding defects is so much easier for the good guys makes it reasonable in many cases to assume that the bad guys probably have not.
Third, the fact is that any secure system design worth its salt does *not* under any circumstances place 100% of its faith in the technology. Monitoring the operation of the system and looking for indicators of potential breaks is essential. In the real world, a broken system can often continue to function just fine as long as those who successfully break it can be tracked down and thrown in prison. In fact, *most* of our real-world "security" relies on this notion of detection and deterrence rather than prevention.
Combine these facts together, and you can see that in this situation it makes more sense to: keep the code and any discovered defects secret (from the world, not from the system operator!); replace the defective devices in a slow, cost-effective trickle; monitor the level of abuse; track down the abusers; and, of course, be ready to shut the whole thing down if the level of abuse becomes intolerable.
In addition to this, the value of a layer of obscurity on *top* of good security should not be disregarded. This is why, for example, the NSA does not publish the details of the ciphers used to secure US military communications.
The common error, of course, is to believe that obscurity is security. It absolutely is not. But, when you understand that no real-world system will ever be perfectly secure, you quickly see that the job of any secure system designer is simply to place enough obstacles in the path of an attacker to convince him that he should go find an easier target. With that mind-set, it's very clear that obscurity can often be a useful source of additional obstacles, as long as one is careful not to overestimate the difficulty of penetrating them.
The current solution is to reset the keys, and using modern mathematics (most of which was developed by Dif) You can do this securely.
Only if you have a place to securely store the private keys. Ya still gotta have secrets at some point. (No, don't go off about how classic Diffie-Hellman has no private keys; you still need secrets for authentication, otherwise you're vulnerable to a MITM attack).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.