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!"

Comments

He's right, you know

[Chocolate Teapot]

The secret to strong security: less reliance on secrets

I have a couple of rottweilers and make no secret of it. Wanna try some social engineering on them?

Ancient Knowledge...

[MarvinMouse]

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. **

Re:Easy Secure Encryption

[KDan]

You fool! As is well known to anyone who follows Microsoft security bulletins (and who knows more about security than Microsoft) you need to use octuple-ROT-13 at least to guarantee good security!

Daniel

Re:Accuracy

[monkeydo]

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."

Open Source encryption tools

[sporadek]

A few years ago I worked on a military messaging system and used some of the source code from Schneier's Applied Cryptography to implement the key exchange, among other things. Everything worked great for us, but not long after it got into the field, we kept having sites come up with errors establishing connections.

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.

Incongrous Thinking...

[airrage]

While you may or may not agree with the "secrets" part of the article, I have to take some umbrage with the author's intent on closed vs. open source as to it's securability.

"There is probably some truth to the notion that giving programmers access to a piece of software doesn't guarantee they will study it carefully. But there is a group of programmers who can be expected to care deeply: Those who either use the software personally or work for an enterprise that depends on it.

But that's the problem with the argument, because study does not equal security. To use the automobile analogy further: many people bought and drive Ford Explorers with Firestone tires, many of whom were probably automobile experts, safety experts, physicists; but the "vulnerability" of a tire blow out causing a fatal crash was never revealed by the consumer. In what organization does anyone look at the code and understand it, but furthermore find the vulnerabilities? That argument seems to crop up as the first few paragraphs in security / technical articles and just never seems to pass muster.

Re:Accuracy

[HawkinsD]

Dude, CNet is a general-audience wide-circulation publication. Yes, the geeks that hang out in here all know this stuff already, but my clients, with whom my company must exchange data securely, may not know anything about why open source is good.

Anything that helps convince my crypto-less clients to use GnuPG is very, very helpful.

Re:Then again...

[R.Caley]

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).

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.

Nope.

[DG]

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