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

12 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
    1. Re:Then again... by schon · · Score: 2, Interesting

      One of his statements begs a question. Diffie says: "A secret that cannot be readily changed should be regarded as a vulnerability."

      Yes, and this is true.

      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.

      And this has what to do with the above statement?

      You said it yourself: the private key being secret.

      In any properly designed system, the key will be easy to change.

      If you design (or use) a system, and can't change the key easily, then yes, it's a vulnerability.

      Solution? make the keys easy to change.

      does Diffie's statement, in a generalised form, kind of nullify the usefulness of asymmetric crypto?

      No. Not Unless you use asymmetric crypto improperly.

  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. Hum by RyoSaeba · · Score: 2, Interesting
    The secret to strong security: less reliance on secrets.
    Now that sounds really like an argument for Open Source, even if he points out that
    A secret that cannot be readily changed should be regarded as a vulnerability
    .
    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)
  4. fun until someone gets hurt ... by HealYourChurchWebSit · · Score: 2, Interesting



    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?
  5. 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.

  6. 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"
  7. To those who bang on that... by Boss,+Pointy+Haired · · Score: 2, Interesting

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

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

  8. quite insightful.. by mmThe1 · · Score: 2, Interesting

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

  9. 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
  10. Re:random eyes by Anonymous Coward · · Score: 1, Interesting

    Poorly written code is IMHO a bug,
    It's probably slow,
    It's definatly hard to maintain
    The design may be poor
    and reuse almost imposible.
    Hard to debug so..
    There are probably bugs that are hard to spot.

    Yeh that's a bug, Just like the screen flashing every five seconds (maybe by design) but it pointless and anoying so it's a bug, in the design.

    OK, you get crap like that wherever you work and it never gets fixed. hmmm.... I hope they don't build bridges that way (though they probably do).