Slashdot Mirror

← Back to Stories (view on slashdot.org)

Decrypting the Secret to Strong Security

Posted by michael on from the common-sense dept.

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

6 of 261 comments (clear)

  1. Then again... by KDan · · Score: 4, Interesting

    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
  2. Re:FP! ...anyway... by Anonymous Coward · · Score: 3, Interesting

    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.

  3. Open Source encryption tools by sporadek · · Score: 5, Interesting
    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.

  4. Incongrous Thinking... by airrage · · Score: 5, Interesting
    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.
    --
    "This isn't a study in computer science, its a study in human behavior"
  5. Nope. by DG · · Score: 5, Interesting

    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
  6. Re:To those who bang on that... by schon · · Score: 4, Interesting

    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.