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

261 comments

  1. Accuracy by Anonymous Coward · · Score: 2, Funny

    who has probably has forgotten more about crypto than 99.9% of us will ever know

    What's the margin of error on that figure?

    1. Re:Accuracy by RealAlaskan · · Score: 1
      >>who has probably has forgotten more about crypto than 99.9% of us will ever know
      >What's the margin of error on that figure?

      How about (-0.0,+0.1)?

    2. Re:Accuracy by Anonymous Coward · · Score: 4, Funny

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

    3. Re:Accuracy by monkeydo · · Score: 5, Insightful

      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
    4. Re:Accuracy by uradu · · Score: 1

      >> who has probably has forgotten more about crypto than 99.9% of us will ever know
      > What's the margin of error on that figure?

      I'm more intrigued by the obviously new tense introduced in that sentence. Its expressive possibilities are quite are staggering.

    5. Re:Accuracy by HawkinsD · · Score: 5, Insightful
      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.

      --
      Never attribute to malice that which can be explained by mere idiocy.
    6. Re:Accuracy by MamasGun · · Score: 1

      It was not written for geeks, it was intended to be a great article to print out and give to the PHB. It's short and to the point...Executive Summary-style.

      --
      "But you've already got a DVD. It lasts forever....In the digital world, we don't need back-ups..."
      -- Jack Valenti
    7. Re:Accuracy by Aaron_Pike · · Score: 1
      True. I know this stuff, and you know this stuff, but this article will help out a lot of non-geeks out there. Personally, I find it particularly useful, because as a high-school CS teacher, it makes geekery a lot more accessible to my proto-incipient hackers, software engineers, and network techs, making my job all the easier.

      So I say, "Up with articles by experts that explain the basics of secutiry, the internet, and all!"

    8. Re:Accuracy by BACbKA · · Score: 1

      Agreed wrt the clients, but definitely the /. submission suggested more. "A definite *must read* for anyone concerned about security...and that should be everyone!" - that doesn't say "unless you're a geek with at least basic knowledge of security vs secrecy issues". This plus the big name (Diffie's) made me RTFA which I probably wouldn't have if I knew who it actually is aimed at.

      --

      VKh

    9. Re:Accuracy by rirugrat · · Score: 1
      Dude, CNet is a general-audience wide-circulation publication.

      Dude...you're getting a Dell!

      Steven

    10. Re:Accuracy by jhoffoss · · Score: 1

      That still doesn't make the article a "great article" on slashdot...most everyone here is more knowledged on subjects such as computer security than your clients, which is why they hire you. This article is "great" for them, not for us.

      --
      Linux: The world's best text-adventure game.
    11. Re:Accuracy by f97tosc · · Score: 1

      who has probably has forgotten more about crypto than 99.9% of us will ever know

      What's the margin of error on that figure?


      Actually, this is not one the very common cases of excessive decimals.

      Rather this could be rephrased as "less than 0.1%", which has only one significant digit; indicating that it could be for example 0.07% or twice as much, 0.14%. Mathematically the difference is a deduction from 100%, which of course we know with infinite accuracy.

      Of course the number was just made up on the spot, but it does not suffer from an excessive amount of decimals.

      Tor

    12. Re:Accuracy by sfe_software · · Score: 1

      It's like someone at CNET said, "Give us 1,000 words on why OSS is good."

      I'm not sure open algorithyms == open source. Many implementations of open standards (SSL, PGP, etc) are in fact closed-source, for their own reasons. Sure, the crypto functions are based on public standards, but that doesn't mean they are in any way supporting open source.

      Granted, some of the same principals apply (which is likely why he mentioned OSS vs Closed Source first); things like "fix the vulnerabilities instead of hiding them", or "let's all work together and agree on a standard, then perfect it". But in the end, the concept applies equally to closed-source applications that happen to use an open standard for a specific function.

      All in all, he doesn't really bring any conclusions about whether OSS is better than the alternative; instead, he draws a parallel to crypto standards, which are, generally, open for very different.

      --
      NGWave - Fast Sound Editor for Windows
    13. Re:Accuracy by sfe_software · · Score: 1

      ...may not know anything about why open source is good.

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


      One can obtain the same security with closed-source applications that also happen to be based on the same open PGP standard.

      In other words, open source != open standards. I don't see this argument pushing open source at all, really. The author simply draws a parallel between OSS and open standards, though the reasons for each being "open" are, generally, different. There are some similarities of course, but the point is, open standards are quite often used in closed-source applications. SSL, PGP, and many other crypto standards are found in proprietary applications.

      It is a great argument for why the user should be using open standards, but does nothing to push open source.

      --
      NGWave - Fast Sound Editor for Windows
  2. FP! ...anyway... by MmmmAqua · · Score: 4, Informative

    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!
  3. Easy Secure Encryption by Anonymous Coward · · Score: 4, Funny

    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.

    1. Re:Easy Secure Encryption by KDan · · Score: 5, Funny

      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

      --
      Carpe Diem
    2. Re:Easy Secure Encryption by haystor · · Score: 2, Funny

      Can anyone from a non-DMCA country crack his ROT-13 and translate? I'd love to know what this guy said.

      --
      t
    3. Re:Easy Secure Encryption by FroMan · · Score: 3, Funny

      You could always rot26 it since, that would be twice as secure as rot13.

      OR!

      I always use primes... everyone in crytology knows you need to use primes. So, you have to use two primes, like rot13 it 5 times, then 3 times. How do you think its going to work without using primes?

      OR!

      Another way to secure your data is to use rot(prime). I also found that you can rot3 and then rot23 it, or even rot7 and rot19.

      Luckly I didn't do that to this post or else it might have been impossible to ever read.

      --
      Norris/Palin 2012
      Fact: We deserve leaders who can kick your ass and field dress your carcass.
  4. Security by Alcohol+Fueled · · Score: 3, Insightful
    "In fact, auditing the programs on which an enterprise depends for its own security is a natural function of the enterprise's own information-security organization."

    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! (\(-__-)/)
  5. He's right, you know by Chocolate+Teapot · · Score: 5, Funny
    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?
    --
    Modest doubt is called the beacon of the wise. - William Shakespeare
    1. Re:He's right, you know by caluml · · Score: 2

      Do they check all the IP packets arriving at your computers then? :)

    2. Re:He's right, you know by Anonymous Coward · · Score: 2, Funny

      "Social engineering" on a Rottweiler is actually very easy. You bribe the dog with a nice tasty steak (or a big doggie biscuit, or some other treat).

    3. Re:He's right, you know by seschmi · · Score: 1

      Did you ever read the book "Smilla's Sense of Snow"? It tells you that a large piece of meat filled with tranquilizers is quite usefull in such a case...
      Actually, the rottweilers deny any kind of service afterwards.

    4. Re:He's right, you know by maxume · · Score: 0, Offtopic

      There is some crappy movie where a thief or some such guy exploits what he knows about dobermans, by making peanut butter balls that are covered in hamburger. The dogs go straight for the meat, and then don't do a whole lot else, as the peanut butter sticks to the roofs of their mouths. Not really social engineering, but it seems related, somehow...

      --
      Nerd rage is the funniest rage.
    5. Re:He's right, you know by Chocolate+Teapot · · Score: 2, Funny

      Every seen how much steak it takes to bribe a Rottweiler? It's gonna cost you an arm and a leg ;)

      --
      Modest doubt is called the beacon of the wise. - William Shakespeare
    6. Re:He's right, you know by uochoa · · Score: 1

      Actually,if they are male, a couple of female rottweilers would do the trick.

    7. Re:He's right, you know by Anonymous Coward · · Score: 0

      Not if I hollow out the steak and fill it with Rat Poison and then marinate it overnight in Anti-freeze.

    8. Re:He's right, you know by Jason+Earl · · Score: 1

      I wouldn't even think about bribing a rottweiler with a steak that didn't weigh more than I do.

    9. Re:He's right, you know by rthille · · Score: 1

      I've found that with a lot of dogs (haven't met yours) that just acting like a bad-ass will usually cow them, or at least make them less likely to press an attack. Something about pack dynamics...

      --
      Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
    10. Re:He's right, you know by stinky+wizzleteats · · Score: 3, Funny

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

      No problem. For my demonstration, I will require a large explosive robot dressed in a female rottweiler suit.

    11. Re:He's right, you know by Anonymous Coward · · Score: 0
      I have a couple of rottweilers and make no secret of it. Wanna try some social engineering on them?

      if they dont have bees coming out of their mouths then i'm not impressed.

    12. Re:He's right, you know by SoSueMe · · Score: 1

      I have a couple of rottweilers...

      Now add eleven more and there's a "ROT13" that would make me feel secure!!

    13. Re:He's right, you know by dzelenka · · Score: 1

      Dude, I just know you're in Mensa when you pun like that!

      --
      Bah!
    14. Re:He's right, you know by Anonymous Coward · · Score: 0

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

      Sure. can i get you to wear these steaks while i try to break-in to your place? :)

  6. Secrecy DOES equal Security by MojoMonkey · · Score: 2, Funny

    ... unless a woman enters the loop!

    --

    ----- "Blame the guy who doesn't speak English." -- Homer J. Simpson
    1. Re:Secrecy DOES equal Security by Anonymous Coward · · Score: 0

      Dear sir,

      You have never ever seen a woman, you never will, your joke is uncalled for, it is bad, not funny, and represents why you will never, ever score. It is your fault, and the fault of many of your peers, that computer scientists will never reproduce fast enough to keep the computer revolution alive. Sorry, but you've been warned, now shut up and stop posting.

      Love,

      Your Secret Admirer.

    2. Re:Secrecy DOES equal Security by Anonymous Coward · · Score: 3, Funny

      ... unless a woman enters the loop!

      So that must mean that most slashdotters are the most secure people on the planet.

    3. Re:Secrecy DOES equal Security by MojoMonkey · · Score: 3, Funny

      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
    4. Re:Secrecy DOES equal Security by Anonymous Coward · · Score: 0

      SOME KIND OF JACKASS forgot to turn off his italics, yyou get it??? you should ,because you ust just made a comlpete complete ass of yourself !! way to go, everybody still hates you, worthless pennnypincher pennypincher.

      hey that chick from inspector gadget is probably pretty old now, she might be hot

    5. Re:Secrecy DOES equal Security by Anonymous Coward · · Score: 0

      Perhaps you should have previewed your own post:

      'yyou', 'ust', 'comlpete'.

    6. Re:Secrecy DOES equal Security by Chocolate+Teapot · · Score: 1

      Dear Madam. Bwuahahahahaaaa! Love CT

      --
      Modest doubt is called the beacon of the wise. - William Shakespeare
    7. Re:Secrecy DOES equal Security by LittleBigLui · · Score: 1
      Then what the hell was it that put a gold band on my ring finger???


      well. you probably just fell from the table you were dancing on at the prancing pony and the ring JUST slipped itself on your finger somehow.
      --
      Free as in mason.
  7. random eyes by oliverthered · · Score: 4, Insightful

    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.
    1. Re:random eyes by gorilla · · Score: 1

      Wouldn't bugzilla and other similar bug tracking systems fit into this? If you read some code and think that it needs attention, you raise a bug, and this will either track it until it's fixed, or record a reason why it doesn't need fixing.

    2. Re:random eyes by oliverthered · · Score: 1

      This is only part of the picture.
      I want to know what code has been looked at and what hasn't. Then I can look at areas that have been left for a while or havn't been audited at all.

      Also raising a bug, the code looks a bit shit, is poorly written and probably has a few bugs (in the design), wouldn't get you too far...

      Code documentation is also a bit poor (from the OSS projects I've looked at), if I implement a RFC or spec, I usually referance the RFC or spec sections in the code. so /* whatever
      implmenets RFC 123 section 9.8 */
      myfunction(){ /*RFC 123 sec 5.6 populate the buffer*/

      }

      Some can then look at the code and the RFC and easly perform an audit.

      --
      thank God the internet isn't a human right.
    3. Re:random eyes by gorilla · · Score: 1
      Also raising a bug, the code looks a bit shit, is poorly written and probably has a few bugs (in the design), wouldn't get you too far...

      Well that's a political issue, not a technical issue, and therefore would apply no matter what tools you use.

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

  8. 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 Anonymous Coward · · Score: 0

      If your secret is compromised then so is your data, this is true. But you key can be readily changed.

      A smaller job than, say, changing your crypto software or your Operating system.

    2. Re:Then again... by Anonymous Coward · · Score: 3, Informative

      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

    3. Re:Then again... by ice+cream+koan · · Score: 1

      I think the key part of that statement is "a secret which cannot be readily changed". Of course, changing a key pair can be a hassle if many people have and use your old key, but it is certainly far easier than if your entire cryptosystem has to be redesigned from the ground up.

      The idea is that the number and size of the secrets you have to maintain should be as small as possible, and they should be as easy as possible to change. A key in crypto meets that requirement much better than a whole proprietary operating system, if the security of the OS is dependent upon keeping the code a secret. (I realize i'm mixing metaphors here, but you get the idea.)

      --


      "When I was in school, I cheated on my metaphysics exam: I looked into the soul of the boy sitting next to me"
    4. 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.

    5. Re:Then again... by R.Caley · · Score: 5, Informative
      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.

      --
      _O_
      .|<
      The named which can be named is not the true named
    6. Re:Then again... by Forseti · · Score: 1

      You've definitely missed the point. Perhaps actually reading the article might have helped.

      You see, the point is that the private key is a secret that can easily be changed, whereas the way your system works cannot. It's therefore much smarter to rely upon a secret such as a key, rather than source code secrecy.

      --
      Delay is preferable to error. (Thomas Jefferson)
    7. Re:Then again... by dunstan · · Score: 1

      The nub to the key/algorithm business is not necessarily the speed with which it can be changed but the issue of control. As a cryptography user I have no control over the secrecy or otherwise of the algorithm, but when I generate a key pair I am in control of the secrecy of the key.

      Dunstan

      --
      The last scintilla of doubt just rode out of town
    8. Re:Then again... by Anonymous Coward · · Score: 0

      Please learn the meaning of the phrase "begging the question" before using it.

    9. Re:Then again... by KDan · · Score: 1

      No, you missed the point of my post. I'm not talking about the algorythm, I'm talking about the private keys.

      Daniel

      --
      Carpe Diem
    10. Re:Then again... by Anonymous Coward · · Score: 0

      A private key can be changed. Not easily, true.

      I believe this statement to mean something more along the lines of your fingerprint or an eyeball scan: both of which cannot be readily changed. A verification system that uses one of those "secrets" should be considered vulnerable.

    11. Re:Then again... by Chocolate+Teapot · · Score: 1

      He used it correctly. The article states "A secret that cannot be readily changed should be regarded as a vulnerability." This assumes the truth of an unproven statement. It begs the question. Just because many people these days misuse the expression, do not assume that every time someone uses it they are incorrect. Perhaps you should read his comment again.

      --
      Modest doubt is called the beacon of the wise. - William Shakespeare
    12. Re:Then again... by p3d0 · · Score: 1
      Let's keep reading, shall we?
      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.
      People aren't as committed to their keys as they are to their algorithms or their operating systems. So secret keys are better than secret algorithms or secret OSes. That's all he's saying.

      And, if the situations you listed are accurate, and those secrets really are hard to change, then yes, I think Mr. Diffie would agree with you that those systems are vulnerable.

      --
      Patrick Doyle
      I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
    13. Re:Then again... by Anonymous Coward · · Score: 0

      I think you missed the point. It isn't possible to have security with NO secrets. The best you can do is minimize the secrets and the impact of changing them.

    14. Re:Then again... by Anonymous Coward · · Score: 0

      It's just you. Any encryption scheme has an element that must be secret to be effective. Unless you just want to one-way encrypt and never recover (useless, for practical purposes). Passwords are a common example, but keys serve the same function.

      What the author is talking about is the actual code used to perform the encryption. When you make this secret, you're betting that your developer(s) are smarter than all others in the world combined. This is delusional, at best.

      When you make them public (obviously before you use them) you give all crypto experts in the world a chance to pound on the algorithm before you rely on it. In the later scenario, you are likely to find flaws before hand. In the former, it is highly likely that a crack will be found and that you won't know about it until damage is done.

      If your keys are compromised in asymmetric (say in PGP), you can always stop using the key and (in PGP's case)revoke it. But any compromise only effects *you*. OTOH, if PGP itself is compromised, everyone who uses PGP is compromised and it may not be possible to fix the algorithm.

      The damage done to you would be the same. But you're only one person, and it would have been your own dumb fault if you allowed someone to attain your private key. And more importantly, the same can happen with a secret algorithm, which does nothing to eliminate the need for keys.

    15. Re:Then again... by lynx_user_abroad · · Score: 1
      If you're going to use asymmetric crypto for legal purposes, to sign stuff, for instance, then the secret cannot be easily changed...

      Not really. Clearly I can have any number of cryptographic signatures which are valid for me. I could change them daily, if I'm willing to bear the transaction cost of ensuring each new signature is accepted as valid. A one-year time frame seems about right to me.

      And if I'm using a new signature, I'll certaintly want to ensure that no one accepts any of my old signatures as valid. So we add an expiration date to the signature: Valid only until...

      Anyone asking for my signature will want to ensure the signature provided has neither expired not been revoked, as part of their own due dilligence. Anyone attempting to prove my signature against my repudiation would be well served by showing not only my valid signature, but proof that the signature was made while it was still valid. (That's why, even in a non-cryptographic and non-digital world, it is common to have important signed documents (such as deeds of trust) recorded promptly with a fair arbiter.) Then, if I later claim compromise of my signature, it becomes my burden to prove that my signature was compromised at the time (and within the historical context of) the signature was known to have occurred.

      --

      The thing about things we don't know is we often don't know we don't know them.

    16. Re:Then again... by Gordonjcp · · Score: 1

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

      Umm, no. You fail it.

      Once an item is signed, you only need the public key to verify the signature. Also, there is a method by which you can create, given your key pair, a pair of "revocation certificates" that you use to prove that your key is yours, and is indeed invalid.

    17. Re:Then again... by Anonymous Coward · · Score: 0

      You seem to be confusing digital signatures, which are methods of validating the data, with encryption, which are methods of concealing the data. A signature cannot be valid for a set length of time as you suggest when you say "as long as a signature needs to be valid". It is always valid. Once the secret key is compromised, however, no future signings using that key can be considered valid.

    18. Re:Then again... by rsdio · · Score: 3, Informative
      Actually, Diffie's greatest invention in the field of public-key cryptography -- the Diffie-Hellman key exchange -- does not require secrets to be kept for long periods of time, which is one of the coolest things about the algorithm.

      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

    19. Re:Then again... by rthille · · Score: 1

      Yes, but if the attacker has access to encrypted (not just signed) documents, then as soon as your private key is compromised, so are the documents. If you weren't worried about the attacker getting ahold of the documents in their encrypted form, you wouldn't worry about encrypting the document at all.

      --
      Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
    20. Re:Then again... by You're+All+Wrong · · Score: 1

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

      Sign them with a date. That way you can provide a date after which your signature is to be considered invalid, but stuff signed before then is still valid. Of course, if you don't know when your key was compromised then you might have to invalidate everything.

      --
      You're All Wrong

      --
      Your head of state is a corrupt weasel, I hope you're happy.
    21. Re:Then again... by flimflam · · Score: 1

      He was referring to signed documents, not encrypted documents. With a digital signature you aren't trying to prevent people from reading a doc, but guaranteeing the authenticity of the document. (I'm not saying what he says actually works, just clarifying this point...)

      --
      -- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
    22. Re:Then again... by Shimmer · · Score: 1

      You still missed Diffie's point:

      If your key gets compromised, it's easy to get a new one. But if your algorithm gets compromised, you've got bigger problems.

      -- Brian

      --
      The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
    23. Re:Then again... by R.Caley · · Score: 1
      [sorry for the more than usual level of typoes in this and the previous message, Opera has decided today that all my type in boxes will use a bizzare font, and I am very bad at proof reading after I write]

      Yes, but if the attacker has access to encrypted (not just signed) documents, then as soon as your private key is compromised, so are the documents.

      Indeed, the situation for encryption is different. The basic answer here is to realise that an encryption of a document has a lifespan. If it is really essential that no one sees the plain text, then shred the document and burn the bits (or the electronic equivalent). Once you send an encrypted document out into the world, assume it will become public property sooner or later and plan what to do when it does.

      The way I read the `secrecy != security' slogan is that one should always work on the assumption that every secret will be revealed, sooner or later. Security must therefore be built on something more substantial than secrecy.

      As a colourful example, in an intelligence organisation, one would have to assume that any captured agent will spill the beans, and that any agent in the field can be captured at any moment. Hence security comes from limiting the usefulness to the enemy of what any one agent knows, and having backup systems which can let everyone know when someone is captured, so plans can be changed.

      For those of us in less glamourous/dangerous occupations, it comes down to such things as defence in depth. make sure that you can do most things you regularly need to without becoming root, then make becoming root complex, then prevent root logging in remotely, then make sure your non-root logins are secure, then use secure connections, then....

      --
      _O_
      .|<
      The named which can be named is not the true named
    24. Re:Then again... by R.Caley · · Score: 1
      Sign them with a date.

      If I compromise your key, can't I then re-sign my doctored document with last week's date... It's late, so maybe there is a way to block that which doesn't occur to me.

      Lots of this stuff is non-obvious, especially in the presence of cocoa with brandy in it (slurp!).

      --
      _O_
      .|<
      The named which can be named is not the true named
    25. Re:Then again... by Darth_Burrito · · Score: 1

      I must be missing something, if a secret key gets compromised isn't any verification/secret maintained by that key fubar? I guess I understand your point, I'm just not so sure I see how any of the alternatives are any better.

    26. Re:Then again... by sfe_software · · Score: 1

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

      I won't say you've missed the point, but there is a difference. When you distribute a binary-only (for example) and secret algorithym, it's easy enough for one to reverse engineer that code. Obviously something in your PC understands how the code works, and it's only a matter of time and patience before someone, somewhere, figures it out.

      With a "private" key, OTOH, you never give anyone that key. It's "secret", yes, but in a different way. There is nothing given to the users that can easily lead to the private key (without millions of CPU-years anyway).

      Since the algo is known, and public, and heavily tested, the probabilities of it being cracked are slim enough to be considered secure. Much moreso than the probability of someone figuring out your secret (but not public/private key-based) algo.

      --
      NGWave - Fast Sound Editor for Windows
  9. Dear Mr. Diffie, by Anonymous Coward · · Score: 0

    Whitfield Diffie, the co-inventor of public-key cryptography, is chief security officer and senior staff engineer at Sun Microsystems.

    Could you please tell your hardware engineers to join the 21st century and provide full schematics and gerber files to all of your circuit boards? I'd like to examine the security of your hardware. After all, this is a good thing, right? The secrecy helps no one, and I'm only trying to help.

    Thanks so much,
    A Hardware Guy

    1. Re:Dear Mr. Diffie, by Savage-Rabbit · · Score: 1

      Dude! I second that......

      --
      Only to idiots, are orders laws.
      -- Henning von Tresckow
  10. 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.

  11. Ancient Knowledge... by MarvinMouse · · Score: 5, Insightful

    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
    1. Re:Ancient Knowledge... by BlueWonder · · Score: 2, Informative
      Quantum Cryptography has some potential as it provides a mathematically verifiable form of perfect cryptography, since it is one time pads.

      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.

    2. Re:Ancient Knowledge... by The+Creator · · Score: 1

      is if the factoring problem is solved

      I thought it was the discrete logarithm problem?

      --

      FRA: STFU GTFO
    3. Re:Ancient Knowledge... by MarvinMouse · · Score: 2, Informative

      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
    4. Re:Ancient Knowledge... by swillden · · Score: 1

      The RSA problem is reduceable to the factoring problem.

      Not quite. It's easy to see that efficient factoring breaks RSA, but there is no proof that a break for RSA can be converted into an efficient factoring method. Some non-factoring break might exist.

      Almost all of these problems though reduce to a simple NP problem

      No. First, factoring has not been shown to be NP-hard. Second, it's not the case that the other problems used in PK "reduce" to some NP problem. NP problems are "decision" problems, meaning among other things that their output is a single bit, so factoring and the discrete log, for example, cannot be in NP or "reduce" to something in NP. Rather, discrete log is NP-hard, which means that if there exists a poly-time solution to DL then all decision problems in NP are in P (P=NP). This is mostly nitpicking, but I would restate your statement as "Some of the problems on which PK cryptography relies are known to be NP-hard and an efficient solution to one of them would mean that the others are probably tractable as well".

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:Ancient Knowledge... by swillden · · Score: 2, Informative

      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.
    6. Re:Ancient Knowledge... by Anonymous Coward · · Score: 0

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

      Sure - if you're dumb enough to use the algorithm immediately after you develop it. If you're serious about security, then it's far better to make the code public for at least a couple years (and even better to offer an substantial reward for breaking it). Or use an established algorithm, instead. There are a lot of them and it is unlikely that you're going to do any better.

    7. Re:Ancient Knowledge... by MarvinMouse · · Score: 1

      Very true, but my point was more on the fact that using security through obscurity is not the most effective way for security, and that rather you need to use proper algorithms. If you decide to obscure this after the point, that's your own business, but a determined opponent will _always_ be able to break through your obscurity.

      On the MITM point...

      ah... yes... I hate these bugger MITM attacks, they are so hard to protect against. So, this is where common sense comes into play. You still have to assume that the key can be easily discovered, and then judge from there whether or not the data you are protecting is worth setting up a MITM attack on (for your enemies.) If it is, then you should reconsider the security as a whole.

      --
      ~ kjrose
    8. Re:Ancient Knowledge... by swillden · · Score: 1

      Sure - if you're dumb enough to use the algorithm immediately after you develop it. If you're serious about security, then it's far better to make the code public for at least a couple years (and even better to offer an substantial reward for breaking it). Or use an established algorithm, instead. There are a lot of them and it is unlikely that you're going to do any better.

      This has nothing to do with algorithms... of course you use widely-known and well-respected algorithms, but the algorithms make up about 1% of the code. What about the rest?

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    9. Re:Ancient Knowledge... by swillden · · Score: 1

      Very true, but my point was more on the fact that using security through obscurity is not the most effective way for security, and that rather you need to use proper algorithms.

      There's the first misunderstanding -- I take it for granted that you're going to use public, trusted algorithms, it's all the *rest* of the code that I'm concerned about. The weaknesses almost *never* arise from the algorithms. The weaknesses arise from, e.g., errors in key management that leak key bits, or errors in permissions enforcement, which permit an attacker to gain privileges he should not have, etc.

      You still have to assume that the key can be easily discovered, and then judge from there whether or not the data you are protecting is worth setting up a MITM attack on (for your enemies.) If it is, then you should reconsider the security as a whole.

      MITM attacks are easy to mount under many, many scenarios. If you data isn't worth the effort of a MITM attack, it's probably not worth the effort of reading. If your system isn't secure againt MITM, it's not secure. Period.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    10. Re:Ancient Knowledge... by Anonymous Coward · · Score: 0

      Diffie is definitely the guy to be talking about this. Considering a main form of private key-exchange is called Diffie-Hellman.

      Oh, but everyone knows the real work was all done by Hellman. Duffie mostly just brought the coffee.

    11. Re:Ancient Knowledge... by Anonymous Coward · · Score: 0

      Diffie is definitely the guy to be talking about this. Considering a main form of private key-exchange is called Diffie-Hellman.

      No, that just means he's a clever guy with a bit of number theory.

      You say you're a CS/Math undergrad. He's no more qualified than you are to talk about security.

    12. Re:Ancient Knowledge... by MarvinMouse · · Score: 1

      MITM attacks are easy to mount under many, many scenarios. If you data isn't worth the effort of a MITM attack, it's probably not worth the effort of reading. If your system isn't secure againt MITM, it's not secure. Period.

      Again, very true. I am just commenting on how common and easy MITM attacks are and how often people don't consider them as part of the "equation" so to speak.

      A secure system has to be secure again MITM, using TTPs or any other methods. But, I just say that in the absolutely worst case scenario, if you might lose the data due to a MITM attack (even with TTPs, or other types, look at the IE bug that allowed a MITM attack on SSL), and it is important that the data isn't lost. You should completely reconsider the system you are setting up, and see if there is a better way to do it.

      --
      ~ kjrose
    13. Re:Ancient Knowledge... by swillden · · Score: 1

      I'm not sure I completely follow you, but if you're saying that you have to consider every eventuality -- absolutely. I generally don't have to worry about MITM attacks, because the systems I work on almost never use public key cryptography, and MITM isn't a concern for symmetric systems(*). However, there are other concerns that arise.

      Something most academics don't understand is that designing secure systems isn't about algorithms or protocols, it's about threat models, risk levels and mitigation strategies. The mitigation strategies often incorporate elements of technology, but just as often include less "interesting" stuff like policies, procedures, oversight, audit trails, legal action and, yes, obscurity. Whatever you can do to cover all the bases...

      (*) I consider PK something to be avoided whenever possible, and find that for high assurance systems, it doesn't solve any real problems anyway. In practice, if you need high security you have to have such high assurance on the CA public keys that there is next to no difference at all between the procedures used to securely authenticate and transport a signer's public key and the procedures used to securely transport and install a secret key. Besides the fact that it's not as useful as many people think, PK vastly complicates the security model and the key management infrastructure, making analysis much more difficult. Also, the storage and processing requirements make PK unusable on very small devices. That isn't to say that PK has no value: it solves some problems that cannot be solved any other way. But it's far less useful than many would believe.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    14. Re:Ancient Knowledge... by MarvinMouse · · Score: 1

      ah, okay. I see where our confusion lies.

      I am emphasizing with cryptography on the internet (which uses mainly PK systems), as well I am emphasizing products which are distributed on a large scale basis.

      Very true about the threat models, etc. Personally though, I believe that the algorithms or protocols are vital for a system to be secure. As well, as policies relating to the software on the system. Obscurity is good if the system isn't distributed large scale.

      So, with my viewpoint of a large scale distribution of a software product that requires security over a medium such as the internet. My initial statement that security through obscurity is useless is accurate.

      But, with your viewpoint of more smaller scale distributions, it does make sense to use these other techniques to improve the security of the system.

      You are accurate in that I think as an academic, but I have worked in the security field as well, and I am well aware of the "less interesting stuff" that is definitely needed to maintain a high enough level of security. I am just of the group of thought that tries to make the system secure, even if the worst case scenario happens. (Which includes the "opposition" acquiring the software and thus destroying the obscurity of the product.)

      Obscurity is good in the sense that you shouldn't go out and advertise exactly what you do, but you shouldn't just assume the opponent doesn't know. That's my feelings on the situation.

      --
      ~ kjrose
    15. Re:Ancient Knowledge... by swillden · · Score: 1

      I am emphasizing with cryptography on the internet (which uses mainly PK systems), as well I am emphasizing products which are distributed on a large scale basis.

      Actually, most of the systems I work on use the Internet for transport, and, as far as scale, would you not consider 4 million users large scale?

      Personally though, I believe that the algorithms or protocols are vital for a system to be secure.

      They're an essential tool and given that a smart attacker will always go after the weakest link, it's critical that they not be weak. In practice, they're so good that no attacker even thinks about attacking them, which means they're not really a major focus for designers. With regard to protocols, the goal is to avoid inventing anything wherever possible, and to subject the result to intense scrutiny whenever you do have to invent something. And there's never any point in keeping your algorithms or protocols secret. Publish them far and wide.

      What is worth keeping secret, in many cases, is your implementation.

      Of course, if you're putting your software on PCs, keeping your implementation secret is a complete impossibility, and even keeping your source code secret adds only minor hurdles. But, if you're talking about Internet-connected PCs, then there is no security anyway, so it's not worth getting too worked up over.

      But, with your viewpoint of more smaller scale distributions, it does make sense to use these other techniques to improve the security of the system.

      The issue isn't one of scale; one of my projects could possibly (not likely, but posibly) have over 100 million users within 10 years or so. The issues center around what level of security is required and what tools are available.

      I am just of the group of thought that tries to make the system secure, even if the worst case scenario happens. (Which includes the "opposition" acquiring the software and thus destroying the obscurity of the product.)

      Well, first, the obscurity is only an additional obstacle placed in the attacker's path; if I realistically thought that publishing the code would make the system insecure, I'd go back to the drawing board. Second, the "worst case" is that a security defect is discovered by the bad guys and they find a way to exploit it on a sufficiently large scale -- whether or not they get hold of the code really isn't relevent. In many environments, the answer is simple: patch the problem. In some, however, that easy answer is not an option, so obscurity is a useful risk mitigation strategy. It's imperfect, but you do what you can. In some environments, obscurity isn't feasible. I'm not sure what you could do in a situation where patching and obscurity are both impossible.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    16. Re:Ancient Knowledge... by MarvinMouse · · Score: 1

      Just as a clarification.

      large-scale implies for me so many users that if a bug is found, it would be near impossible to "patch" all of the machines.

      As well, large-scale also implies that key-distribution must be reliant on PK, since all other methods are too difficult to do or easy to intercept (ie. the opponent may have a copy of your code and can just "look up" the key).

      Excellent point on this

      "And there's never any point in keeping your algorithms or protocols secret. Publish them far and wide."

      This I agree with fully, and is what I mean by obscurity not being that useful. Some companies use obscurity to cover for bad algorithms or bad implementations. This is what I agree is very bad.

      I'm not sure what you could do in a situation where patching and obscurity are both impossible.

      To be honest, there's not much you can do at all in this situations. (I have been in one.) It's very difficult to set up a key on two computers with a high enough entropy that both sides know, and isn't distributed in an easily interceptable way. Examples of doing this include asking the user for a long password that is used to randomly generate a key, but the password's entropy just isn't really that high for most users. (Unless you put incredible controls on it.) As well, if the system is ever compromised, you have to redistribute a key, and well.. it's just not fun at all.

      PK provides a way around this, but even then, the requirement of TTPs and other methods to handle MITM attacks makes the whole ordeal very very painful.

      Patching is possible, but as soon as you allow for patching, you allow for other types of attacks that are again not very good to have around (incl. variations on MITM attacks).

      The most important fact about security I have realized with my experience is that if the enemy wants your information enough, they'll get it, and there isn't much you can do to prevent it. So, you have to make a "risk assessment" or as I put it a "judgement call" on whether or not the risk of losing that data is too high. If so, then alternatives need to be thought up.

      I am interested to hear where you've got all of your experience in cryptography and security, as you obviously are very experienced in the field.

      --
      ~ kjrose
    17. Re:Ancient Knowledge... by swillden · · Score: 1

      large-scale implies for me so many users that if a bug is found, it would be near impossible to "patch" all of the machines.

      By this definition, all of my projects are "large-scale".

      As well, large-scale also implies that key-distribution must be reliant on PK, since all other methods are too difficult to do or easy to intercept

      This has nothing to do with scale, and everything to do with the technology employed for key management and key distribution.

      (ie. the opponent may have a copy of your code and can just "look up" the key)

      The key should not be in the code; it should be stored in a safer location (what that means varies). In addition, every user should have a different key. Essentially, this is what PK is used for: to permit every user's key to be different. In PKI, a TTP is used to authenticate the keys. With symmetric systems, the TTP issues the user-unique keys. In some environments it would be bad for the TTP to issue the keys (which implies that the TTP has the keys), but in many more environments, the "TTP" in question is actually the "owner" of the entire system, and has absolutely zero interest in defeating the security in any way -- quite the opposite, in fact. However, the TTP/owner is a corporation, and corporations are made up of people, whose goals don't necessarily coincide with those of their employer...

      To be honest, there's not much you can do at all in this situations. (I have been in one.) It's very difficult to set up a key on two computers with a high enough entropy that both sides know, and isn't distributed in an easily interceptable way.

      If you're talking about standard PCs, don't worry because they're completely insecure anyway. Beyond that, I'd clarify that establishing an adequate shared key is trivially easy -- verifiying that you've established a key with the *right* remote computer can be the hard part. There are actually a zillion different solutions to this problem, each with different characteristics, including different levels of security. One widely-used approach, for example, involves cryptographic keysplitting and transmission of the keyparts through multiple, independent and independently verifiable channels. *Highly* secure when done correctly. Another is physical shipment of a secure hardware token. I'm sure those techniques are inappropriate for the situation you're considering, but you might reflect on why, exactly, they're inappropriate. I suggest it's because the data you're protecting isn't valuable enough to warrant such measures.

      In situations where security isn't, in fact, all that important, it's perfectly reasonable to accept limited security. That doesn't mean working hard to define protocols that are as tight as possible doesn't make sense, because it occasionally does -- and it's really fun -- but you have to realize that you're putting a bank vault door on a picket fence.

      PK provides a way around this, but even then, the requirement of TTPs and other methods to handle MITM attacks makes the whole ordeal very very painful.

      Which means that, in practice, PK *doesn't* really provide a way around it.

      Lest you think I'm dissing PK, let me clarify that I use it in my work. The primary advantage of PK is that it reduces the requirements of the key distribution process. To wit, rather than having to distribute a symmetric key that must be both authenticated *and* secret, you have to distribute a public key that only needs to be authenticated, no secrecy required. Well, and you also have to appropriately manage the corresponding private key and it's use. Oh, and then there's revocation, but that's a problem with both symmetric and asymmetric tech.

      Patching is possible, but as soon as you allow for patching, you allow for other types of attacks

      Yes, patching is also problematic. The fact is that you not only have to authenticate your keys, you also have to authenticate your code (often harder, since it's larger), and so you have the public key distribution problem reprised. If you want to keep the code secret, you have the symmetric key distribution problem.

      And patches require the same level of assurance. If you want to read some interesting stuff about a team that attacked this problem head-on, read the IBM 4758 crypto card design whitepaper.

      The most important fact about security I have realized with my experience is that if the enemy wants your information enough, they'll get it, and there isn't much you can do to prevent it. So, you have to make a "risk assessment" or as I put it a "judgement call" on whether or not the risk of losing that data is too high. If so, then alternatives need to be thought up.

      I generally look at it in terms of dollars. Two questions:

      1. What is the dollar cost to a hypothetical attacker (defining precisely the capabilities and motivations of the set of hypothetical attackers is a major -- and very difficult -- part of threat modeling) to break the security via each route that I can foresee?
      2. What is the dollar value to a hypothetical attacker of breaking the security? This is more complex than it might appear at first sight, since it has to include all sorts of non-obvious value, including notoriety, corporate competitive advantage, PR, etc.

      If (1) > (2), then your design's not done. If you can find no way to reverse that inequality, then the answer is: Don't do it. Of course, there's a huge amount of guesswork in the terms of that inequality but, again, you have to do the best you can. Oh, and (1) and (2) are vectors, not scalars; you have one term for each type of hypothetical attacker.

      I am interested to hear where you've got all of your experience in cryptography and security, as you obviously are very experienced in the field.

      I'm the lead architect/security consultant for IBM Global Services' Global Smart Card Solutions organization; a position I've held for about four years. I have an academic background in cryptography, acquired in the course of my math and CS degrees, and a "practical" background in physical security, acquired from my stint as a Security Specialist in the US Air Force Reserves (there's a long story about how I ended up doing that -- I have no regrets). Through practical experience and opportunities to rub shoulders with some real experts (folks from IBM Research, mainly -- not Don Coppersmith, unfortunately, though we've exchanged e-mails), I've put some polish on those theoretical underpinnings.

      How about you?

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    18. Re:Ancient Knowledge... by MarvinMouse · · Score: 1

      If (1) > (2), then your design's not done. If you can find no way to reverse that inequality, then the answer is: Don't do it. Of course, there's a huge amount of guesswork in the terms of that inequality but, again, you have to do the best you can. Oh, and (1) and (2) are vectors, not scalars; you have one term for each type of hypothetical attacker.

      Exactly! That's the key thing I always keep in mind with my security, and I have found when I do security evaluation of products, it's something most people don't consider. (You do not know how many products I have found with keys in the code, or 1 or 2 byte entropy on the keys.) I do acknowledge though that smart cards are making the software more secure. As well, as a few other interesting techniques. Overall though, I find most people who program security software are not as aware of this point, and assume that their enemy isn't as prepared as they think, just from lack of experience.

      How about you?

      Actually, I am a pure mathematics student at the University of Waterloo (with a in-depth CS background) who has worked as a co-op student recommending security to portions of the Canadian Space Agency, as well been involved in cryptographic research, internet design and security evaluation with other jobs.

      --
      ~ kjrose
    19. Re:Ancient Knowledge... by swillden · · Score: 1

      Exactly! That's the key thing I always keep in mind with my security, and I have found when I do security evaluation of products, it's something most people don't consider.

      Well, it's something most amateurs don't consider, anyway :-)

      The funny thing about it is that, once you understand the principle, it all seems so obvious. Obvious, of course, does not necessarily mean simple. (Like the old joke about the math prof who wrote a lemma on the board and said "It's obvious that...". A student raised his hand and said "Are you sure that's obvious"? The professor paused, looked at the board, ran to his office, scribbled furiously for an hour and then returned, stating "Yes, it is obvious.").

      I am a pure mathematics student at the University of Waterloo (with a in-depth CS background)

      Pure math was one of my majors as well :-) You might appreciate this little tagline I used from time to time:

      Never trust a humble mathematician.

      My uncle trumped me once though, when he responded to the tagline in my e-mail with "I've never *met* a humble mathematician!"

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  12. Well put! by mustangdavis · · Score: 1
    You may be able to keep the exact workings of the program out of general circulation, but can you prevent the code from being reverse-engineered by serious opponents? Probably not.



    There are just too many ways to reverse engineer something these days .... debuggers, de-compilers, etc ....


    This is why everything should be open source! If everthing is put in plain view (and not protected by rediculous laws and coprights), then people that use crypto programs are more likely to ensure that they are truely secure ... and they are able to help contribute to the program by repairing flaws in the original code ...

    If everyone's eyes can see the program, then security can better be kept without an excessive need for an abundense of secrets ...


    Just my $0.02 cents ...

    1. Re:Well put! by Anonymous Coward · · Score: 0

      There is no such word as rediculous.
      When will you people fucking realize this?

    2. Re:Well put! by Anonymous Coward · · Score: 0

      There are just too many ways to reverse engineer something these days
      There's more than that. The source, particularly the comments is tainted by what the designers and coders thought the program is doing. This can be subtly and sufficiently off-target that one one the standard debugging techniques is eliminate all comments so as to not be deluded by them. Reverse engineering must look at what the code actually does (as opposed to what someone thinks it does). Reverse engineering for nefarious purposes will be looking for edge and corner cases, many of which *cannot* be seen once one has swallowed false assumptions built into the comments.
      Reverse engineering

    3. Re:Well put! by Simon+Garlick · · Score: 1

      There are just too many ways to reverse engineer something these days .... debuggers, de-compilers, etc ....

      This is why everything should be open source!


      You still have to trust the compiler that turns your source into something useful.

  13. Funny it should synchronise with this ... by watzinaneihm · · Score: 1

    Microsoft opens winows source to governments.... Link here

    --
    .ACMD setaloiv siht gnidaeR
    1. Re:Funny it should synchronise with this ... by watzinaneihm · · Score: 1

      Sorry Wrong link... Correct link here

      --
      .ACMD setaloiv siht gnidaeR
    2. Re:Funny it should synchronise with this ... by mustangdavis · · Score: 1

      This is going to be funny ....


      All of the MS exploits that will be exposed after some people outside of Microsfot get their hands on MS source code ....


      Of course, then they are going to get the "open source" community to fix these bugs for them (for free), then lock it back up ....


      Hmmm ... this idea for security will help the world as a whole, but may backfire in that MS may exploit the open source community ....


      I guess that is one way to achieve security ... exploit the people and get free labor to plug all of your security holes!!

    3. Re:Funny it should synchronise with this ... by JoeBuck · · Score: 1

      I hope that the governments in question insist on some evidence that the code that Microsoft shows them corresponds exactly to the executables Microsoft ships.

    4. Re:Funny it should synchronise with this ... by CableModemSniper · · Score: 1

      Isnt that as simple as building from source and checksumming the resultant binary against the microsoft-built binary?

      --
      Why not fork?
  14. 100% secure by Master+Rux · · Score: 1

    I think we all know the answer to real security...Unplug your machine and never turn it on.

    --
    IMO the best browser game ever http://wittyrpg.com
    1. Re:100% secure by Alcohol+Fueled · · Score: 1

      Or just don't connect to the Internet. You don't really have to worry about someone wandering across your computer while it's on and using it and screwing with your stuff, if you have permissions set with *really* good and very hard to guess passwords and all.

      --
      Ah am not a crook! (\(-__-)/)
    2. Re:100% secure by binaryDigit · · Score: 1

      Unplug your machine and never turn it on.

      You forgot to throw it into a safe, etc. Many people forget that PHYSICAL security can be just as, if not more, important than "logical" security. After all, how many times in movies have we seen the likes of Tom Cruise access a "absolutely secure" system by "simply" breaking into the location of the system?

    3. Re:100% secure by Master+Rux · · Score: 1

      You're right. I should probably smash the hard drive and destroy any disks that are laying around. YOU'LL NOT GET MY DATA!!!

      --
      IMO the best browser game ever http://wittyrpg.com
    4. Re:100% secure by Alcohol+Fueled · · Score: 1
      "Many people forget that PHYSICAL security can be just as, if not more, important than "logical" security."

      Good point. But of course, physical security won't help at all if the company has a wireless network and there's someone outside in their car or in the restaurant across the street with their laptop, piggybacking on the company's network or looking through it.

      --
      Ah am not a crook! (\(-__-)/)
    5. Re:100% secure by mustangdavis · · Score: 1
      There is only ONE way to achieve REAL security:
      1. Unplug all connections to the machine (including power, internet, keyboard, mouse, serial, printer, USB, firewire, etc)
      2. Place machine in lead box with hinges that can not be drilled that has a combination lock on the opening
      3. Close and lock the lead box
      4. Suck all air out of the box
      5. Plug hole where air was removed with more lead
      6. Encase lead box with a few feet of concrete on all sides
      7. Take dried concrete crate to an undisclosed location, somewhere in the middle of a large body of deep water
      8. Drop server, encased in lead and concrete to the bottom of the deep bod of water
      9. SECURITY ACHIEVED!!



      I'll be here all week folks!

    6. Re:100% secure by binaryDigit · · Score: 4, Insightful

      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.

    7. Re:100% secure by Alcohol+Fueled · · Score: 1
      "There is only ONE way to achieve REAL security: 1. Unplug all connections to the machine (including power, internet, keyboard, mouse, serial, printer, USB, firewire, etc)
      2. Place machine in lead box with hinges that can not be drilled that has a combination lock on the opening
      3. Close and lock the lead box
      4. Suck all air out of the box
      5. Plug hole where air was removed with more lead
      6. Encase lead box with a few feet of concrete on all sides
      7. Take dried concrete crate to an undisclosed location, somewhere in the middle of a large body of deep water
      8. Drop server, encased in lead and concrete to the bottom of the deep bod of water
      9. SECURITY ACHIEVED!! "

      That is, until someone finds the concrete crate, recovers it on a deep sea expedition, jackhammers away the concrete, cracks open the combination lock, opens the safe, and uses the computer to discover gigabyte upon gigabyte of porn!

      --
      Ah am not a crook! (\(-__-)/)
    8. Re:100% secure by Alcohol+Fueled · · Score: 1
      "and/or the passwords are written on the side of the monitors"

      That's if there are any passwords in place. I'm sure there are some people who think that passwords aren't necessary, for some ungodly reason.

      --
      Ah am not a crook! (\(-__-)/)
    9. Re:100% secure by Anonymous Coward · · Score: 0

      I don't know why it is that people now fear so much having a networked machine on. I don't know too much about networking but I do know a machine must have an port open in order for someone else to do something with it. According to what I have been told about public key cryptography, it is very very secure. So using ssh (and thus having the port open) should not be too much of a worry. The only thing I would worry about is information being passed through less secure protocols such as telnet (although I last heard there is now secure telnet) or ftp or even the simple prompt for user and password when accessing a member web site. The latter has a very interesting but crackable encryption. If you know of a way hackers use to get into a computer with all ports closed, please tell me. I am intrigued.

  15. Employee at Sun Microsystems by grungeman · · Score: 1

    How did Sun manage to make him work for them? Security-wise he alone is worth more than Microsoft's whole "Trustworthy Computing" campaign.

    --

    Signature deleted by lameness filter.
    1. Re:Employee at Sun Microsystems by Angry+White+Guy · · Score: 1

      Maybe he has morals, or maybe even he knows what an insurrmountable challenge it would be to make M$ Secure

      --
      You think that I'm crazy, you should see this guy!
    2. Re:Employee at Sun Microsystems by mark_lybarger · · Score: 1, Insightful

      or maybe they just pay him really really good. and have a nice vacation plan.

    3. Re:Employee at Sun Microsystems by grungeman · · Score: 1

      Or maybe they proposed a really cool project to him. That's how you get the really outstanding geeks.

      --

      Signature deleted by lameness filter.
  16. 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)
  17. Re:FP! ...anyway... by Anonymous Coward · · Score: 1, Funny

    secrecy != security

    True, I also tend to rely on complete lack of importance and relevance == Total insecurity.

    I am so pathetic and worthless. Somebody love me?

  18. 'Advocates of proprietary software' by Ed+Avis · · Score: 2, Insightful

    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. So at first it sounds like Mr Diffie is setting up a straw man at the beginning of his article. But then you realize that the 'opponents' are not serious arguments but, on the whole, vague FUD wafting about that may be swallowed by less-technical people. So his article is an attempt to explain to the rest of the world what the security industry already knew.

    --
    -- Ed Avis ed@membled.com
    1. Re:'Advocates of proprietary software' by schon · · Score: 3, Informative

      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.

    2. Re:'Advocates of proprietary software' by Arandir · · Score: 1

      "Security through obscurity" makes an inutitive kind of common sense, unless you think about it for awhile, or are exposed to the flaws

      Almost, but not quite. There is a value to obscurity, albeit extremely low.

      I was forced to use it in a recent project. I cannot say what the project is, but I can give you an analogy. It's not even close to the real situation, but the security implications are nearly exact. Imagine a shrinkwrap box containing a software application. In order to prevent "piracy", you require the customer to call in for a key to unlock the software during installation.

      You cannot rely on your customer having remote access to your key server. You can't ship dongles in the box because of resource limitations. And of course it's not feasible to send out customer support personnel to turn on the software. The final limitation is that all CD's are identical, differing only in the serial number stamped on them. How do you secure it?

      The weak link is the algorithm. The scheme requires a hash. Once you know the hash algorithm and the necessary data to generate a key, it's broken. All you need is the source code (or the key generation program itself) and you're in.

      In the above situation "security through obscurity" is your only choice. It's sucky security but it's still marginally better than no security at all.

      "Would you like live or dead spiders for your breakfast sir?"

      "Ummm, dead please..."

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    3. Re:'Advocates of proprietary software' by schon · · Score: 1

      There is a value to obscurity, albeit extremely low.

      Your attitude reminds me of the following story:

      Two gold miners go into a mine.. they decide they have a higher chance of finding gold if they split up... at the end of the day, they meet up.. the older miner is empty handed, while the younger miner is lugging a full wheelbarrow, and says "Look what I found - there's 4 or 5 hundred pounds of it just over there!"

      The older miner is amazed, and takes a closer look, and says "heh, this is pyrite! It's not worth anything!"... the younger miner says "oh, that's too bad.. oh well, give me a hand loading this up, it should only take us a day or so to get it back to town."

      The older miner then says "but it's fool's gold, why do you want to take it back with us?"

      To which the younger miner replies "Well, it's better than nothing."

      People who argue that obscurity has "some" value miss a very important point: it's worse than no security at all, because it leads you to believe that you're doing something, when actually you're not.

      You cannot rely on your customer having remote access to your key server. You can't ship dongles in the box because of resource limitations. And of course it's not feasible to send out customer support personnel to turn on the software. The final limitation is that all CD's are identical, differing only in the serial number stamped on them. How do you secure it?

      Well, there is something simple here that you're missing. If the customer calls in to register their product, and the only piece of information you're basing your "security" on is the serialnumber, what's to stop the user from registering it, then passing that registration key (and the serial number) on to someone else?

      You've gone to a lot of work and hassle, needlessly inconvenienced the customer, and the end result is that your product is no more secure than it was if you just required them to type in the serial number itself.

      As the younger miner said, "it's better than nothing", right?

      Read this post for another example of why obscurity is worse than nothing at all. (Because it leads him to believe that he's doing something, but in fact his data is no more secure than it would be without his magic URL.)

    4. Re:'Advocates of proprietary software' by Arandir · · Score: 1

      People who argue that obscurity has "some" value miss a very important point: it's worse than no security at all, because it leads you to believe that you're doing something, when actually you're not.

      In our case, we are very much aware that we have an extremely weak link. I made sure the bosses above me knew this. We are certainly not pretending that we have a secure system.

      If the customer calls in to register their product, and the only piece of information you're basing your "security" on is the serialnumber, what's to stop the user from registering it, then passing that registration key (and the serial number) on to someone else?

      In our case we use time limited keys and user IDs, with logging of all authentication attempts.

      But rest assured that we don't consider this adequate security any more than putting a deadbolt on a screen door would be. We've managed to keep out flies and dumb mammals.

      Our reason for the "security" system is not so much for the protection of our IP (although the IP guys glommed onto it as well), but to protect the warranty.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    5. Re:'Advocates of proprietary software' by Ed+Avis · · Score: 1

      When I said 'seriously argue' I meant, like, reasoned debate by people who know what they are talking about. Which is not to say that the peer-review advocates don't have their own personal interests too, even Whit Diffie, but in general they are trying to discuss what makes for better security, rather than just blowing FUD.

      Or in other words: an 'unnamed MS source' quoted on ZDnet does not qualify as serious argument.

      (I mentioned Slashdot trolls because there is a possibility that some of them sincerely believe that binary-only software is more secure.)

      --
      -- Ed Avis ed@membled.com
  19. IANAL, but... by Anonymous Coward · · Score: 4, Funny

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

  20. 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?
  21. Serecy !=Security by joelwest · · Score: 1

    "It's simply unrealistic to depend on secrecy for security in computer software" -- what a succinct way to demolish the DMCA.

  22. Re:Live in a tree by Anonymous Coward · · Score: 0

    Nobody said a thing about trees before this post.

    So yes, this post is redundant.

    How many moderators are in charge of security?

    If that makes you think, you are not a moderator.

  23. MOD THIS PARENT UP!!! by Anonymous Coward · · Score: 0

    THIS post is HILARIus and that is why i think it is funny.

    here is obligitory repost of story!!

    Watch out, Swami: Quickie now 3-1 on the people-competing-with-animals season, following last night's "Man vs. Beast" debacle. Correct: Elephant outracing 44 little people in jet-tug; sprinter placing between zebra and giraffe in 100m; Navy SEAL beating chimp in obstacle course. Missed: Kodiak bear ended up outgorging Japanese hot-dog-eating champ.

    baseball fantasy leagues, there are controls in place to keep ambivalent managers of the going-nowhere teams with a couple great players from unfairly shoveling off those stars for next to nothing. Since Major League Baseball runs the Expos as well as the rules, however, they felt free to offload the best available pitcher, Bartolo Colon, to the White Sox in exchange for an essentially costless El Duque, while the Yankees contentedly reduced their logjam of starting pitchers and added a couple of relievers -- and, oh yeah, snickered at the Red Sox, who had to watch helplessly. Theo, we love ya, but ouch.
    So, you think you cleaned all your personal files from that old computer you got rid of?

    Two MIT graduate students suggest you think again.

    Over two years, Simson Garfinkel and Abhi Shelat bought 158 used hard drives at secondhand computer stores and on eBay. Of the 129 drives that functioned, 69 still had recoverable files on them and 49 contained "significant personal information" -- medical correspondence, love letters, pornography and 5,000 credit card numbers. One even had a year's worth of transactions with account numbers from a cash machine in Illinois.

    About 150,000 hard drives were "retired" last year, according to the research firm Gartner Dataquest. Many end up in the trash, but many also find their way back onto the market.

    Over the years, stories have surfaced about personal information turning up on used hard drives, raising concerns about privacy and the danger of identity theft.

    Last spring, Pennsylvania sold used computers that contained information about state employees. In 1997, a Nevada woman bought a used computer and discovered it contained prescription records on 2,000 customers of an Arizona pharmacy.

    Garfinkel and Shelat, who reported their findings in an article to be published Friday in the journal IEEE Security & Privacy, said they believe they are the first to take a more comprehensive -- though not exactly scientific -- look at the problem.

    On common operating systems such as Microsoft's Windows, simply deleting a file, or even following that up by emptying the "trash" folder, does not necessarily make the information irretrievable. Those commands generally delete a file's name from the directory. But the information itself can live on until it is overwritten by new files.

    Even reformatting a drive, or preparing the hard drive all over again to store files, may not do it. Fifty-one of the 129 working drives in the MIT study had been reformatted, and 19 of them still contained recoverable data.

    The hard-to-erase quality of hard drives is seen as a good thing by some. Many users like believing that, in a pinch, an expert could recover their deleted files. Law enforcement officers can examine a computer and lift incriminating e-mails or porno images from the hard drive.

    The only sure way to erase a hard drive is to "squeeze" it: writing over the old information with new data -- all zeros, for instance -- at least once, but preferably several times. A one-line command will do that for Unix users, and for others, inexpensive software from companies such as AccessData works well.

    But few people go to the trouble. Many ordinary computer users toss their old drives into the closet, or take a sledgehammer to it.

    As it turned out, most of the hard drives acquired by the MIT students came from businesses that apparently had a misplaced confidence in their ability to "sanitize" old drives.

    Tom Aleman, who heads the analytic and forensic technology group at the accounting firm Deloitte & Touche, often encounters companies that get burned by failing to fully sanitize, say, the laptop of an employee who leaves the company for a job with a competitor.

    "People will think they have deleted the file, they can't find the file themselves and that the file is gone when, in fact, forensically you may be able to retrieve it," he said.

    Garfinkel has learned his lesson. As an undergrad at MIT in the 1980s, he failed to sanitize his own hard drive before returning a computer to his father. His father was able to read his personal journal.

    THIS post is HILARIus and that is why i think it is funny.

    here is obligitory repost of story!!

    Watch out, Swami: Quickie now 3-1 on the people-competing-with-animals season, following last night's "Man vs. Beast" debacle. Correct: Elephant outracing 44 little people in jet-tug; sprinter placing between zebra and giraffe in 100m; Navy SEAL beating chimp in obstacle course. Missed: Kodiak bear ended up outgorging Japanese hot-dog-eating champ.

    baseball fantasy leagues, there are controls in place to keep ambivalent managers of the going-nowhere teams with a couple great players from unfairly shoveling off those stars for next to nothing. Since Major League Baseball runs the Expos as well as the rules, however, they felt free to offload the best available pitcher, Bartolo Colon, to the White Sox in exchange for an essentially costless El Duque, while the Yankees contentedly reduced their logjam of starting pitchers and added a couple of relievers -- and, oh yeah, snickered at the Red Sox, who had to watch helplessly. Theo, we love ya, but ouch.
    So, you think you cleaned all your personal files from that old computer you got rid of?

    Two MIT graduate students suggest you think again.

    Over two years, Simson Garfinkel and Abhi Shelat bought 158 used hard drives at secondhand computer stores and on eBay. Of the 129 drives that functioned, 69 still had recoverable files on them and 49 contained "significant personal information" -- medical correspondence, love letters, pornography and 5,000 credit card numbers. One even had a year's worth of transactions with account numbers from a cash machine in Illinois.

    About 150,000 hard drives were "retired" last year, according to the research firm Gartner Dataquest. Many end up in the trash, but many also find their way back onto the market.

    Over the years, stories have surfaced about personal information turning up on used hard drives, raising concerns about privacy and the danger of identity theft.

    Last spring, Pennsylvania sold used computers that contained information about state employees. In 1997, a Nevada woman bought a used computer and discovered it contained prescription records on 2,000 customers of an Arizona pharmacy.

    Garfinkel and Shelat, who reported their findings in an article to be published Friday in the journal IEEE Security & Privacy, said they believe they are the first to take a more comprehensive -- though not exactly scientific -- look at the problem.

    On common operating systems such as Microsoft's Windows, simply deleting a file, or even following that up by emptying the "trash" folder, does not necessarily make the information irretrievable. Those commands generally delete a file's name from the directory. But the information itself can live on until it is overwritten by new files.

    Even reformatting a drive, or preparing the hard drive all over again to store files, may not do it. Fifty-one of the 129 working drives in the MIT study had been reformatted, and 19 of them still contained recoverable data.

    The hard-to-erase quality of hard drives is seen as a good thing by some. Many users like believing that, in a pinch, an expert could recover their deleted files. Law enforcement officers can examine a computer and lift incriminating e-mails or porno images from the hard drive.

    The only sure way to erase a hard drive is to "squeeze" it: writing over the old information with new data -- all zeros, for instance -- at least once, but preferably several times. A one-line command will do that for Unix users, and for others, inexpensive software from companies such as AccessData works well.

    But few people go to the trouble. Many ordinary computer users toss their old drives into the closet, or take a sledgehammer to it.

    As it turned out, most of the hard drives acquired by the MIT students came from businesses that apparently had a misplaced confidence in their ability to "sanitize" old drives.

    Tom Aleman, who heads the analytic and forensic technology group at the accounting firm Deloitte & Touche, often encounters companies that get burned by failing to fully sanitize, say, the laptop of an employee who leaves the company for a job with a competitor.

    "People will think they have deleted the file, they can't find the file themselves and that the file is gone when, in fact, forensically you may be able to retrieve it," he said.

    Garfinkel has learned his lesson. As an undergrad at MIT in the 1980s, he failed to sanitize his own hard drive before returning a computer to his father. His father was able to read his personal journal.

  24. yeahwell by Anonymous Coward · · Score: 0

    when you include ideotic humans security goes to the birds

  25. MY BOX IS UNHACKABLE by zapfie · · Score: 2, Funny

    My IP is 127.0.0.1. Do your worst.

    --
    slashdot!=valid HTML
    1. Re:MY BOX IS UNHACKABLE by sisukapalli1 · · Score: 1


      My IP is 127.0.0.1. Do your worst.


      Aha! Here is a picture of Anna Kournikova saying "I LOVE YOU". Take a look.

      S

    2. Re:MY BOX IS UNHACKABLE by Anonymous Coward · · Score: 0

      YESSSss! I am in... #rm -rf /

      DOH!

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

    1. Re:Open Source encryption tools by slim · · Score: 2, Insightful

      The moral of the story? I suppose it's just this: 'the "many eyeballs" theory quickly breaks down in the face of esoteric algorithms'.

      But.. but...

      You found the bug, and now the world at large knows about it. You are a living example of the "many eyeballs" theory in action. You don't *have* to spot the bug merely by eyeballing the code; witnessing it in the wild counts too.

    2. Re:Open Source encryption tools by datastew · · Score: 2, Informative
      The moral of the story? I suppose it's just this: the "many eyeballs" theory quickly breaks down in the face of esoteric algorithms.
      The follow-on to this story is that Schneier developed blowfish for just this reason, as he talks about here:
      Use a design that is simple to understand. This will facilitate analysis and increase the confidence in the algorithm. In practice, this means that the algorithm will be a Feistel iterated block cipher.
      I am writing a simple app at home using blowfish to brush up on my C++ skills, and I am just a lowly mechanical-engineer-turned-programmer.
    3. Re:Open Source encryption tools by vovin · · Score: 0, Troll

      The moral of the story is that code reviews are bullshit fed to QA.
      The only way to be qualified to review code is to have implimented it independantly. Otherwise all ppl do is go, uh-huh, uh-huh, yeah that looks right...

    4. Re:Open Source encryption tools by Anonymous Coward · · Score: 0

      Umm no, bullshit. That's why nobody would use your crappy open-source non-QAed software. Real companies would prefer to use real software than "0.1.4pre4alpha2rc3woody" shit that you throw at users and expect them to RTFM and submit a patch themselves.

    5. Re:Open Source encryption tools by Rocketboy · · Score: 2, Insightful
      The moral of the story? I suppose it's just this: the "many eyeballs" theory quickly breaks down in the face of esoteric algorithms.


      No, the moral of the story is that you found the error and corrected it, thus solving the problem. Could you have fixed it if you didn't have the source?


      Programmers and designers make mistakes. Programmers and designers will probably always make mistakes. The real issue is how do you find and fix the errors, whether they are based in the code or the algorithm or in the application logic. If you can't see the source, that's just one more obstacle in the way, one more source of noise to work through.

    6. Re:Open Source encryption tools by Anonymous Coward · · Score: 0

      You've proven the point you tried to disprove.

      The many eyeballs theory *does* work. You've demonstrated it. There was a bug in the code, and when you ran across it, you troubleshot with the code, found the bug, and (hopefully) submitted the fix to the author. Your eyeballs fixed it! If the code was closed, you wouldn't have a prayer of fixing it.

      Eyeballs doesn't mean just reading the code. It means the entire code review, testing, and user process.

    7. Re:Open Source encryption tools by jim3e8 · · Score: 1

      You say you didn't have a clue what the cryptographic algorithm you copied did. How can you expect to find a bug, then, or an error in implementation? It is especially true in cryptographic software that you need to completely understand what you're doing.

      Now, if you had unleashed your code to the world, then someone might have spotted the error. And that's why it's called the many eyeballs theory--because what your team of 10 non-cryptographers fails to catch, another thousand eyeballs might.

      By the way, the virtues of the "many eyeballs" theory have been noted in the cryptographic field since 1870, as Diffie says, and those esoteric algorithms are only better for it.

    8. Re:Open Source encryption tools by lildogie · · Score: 1

      > ...
      > 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).
      > ...
      > When we got rid of the special function and
      > instead used the overloaded * and % operators,
      > everything worked fine.
      > ...
      > The moral of the story? I suppose it's just
      > this: the "many eyeballs" theory quickly breaks
      > down in the face of esoteric algorithms.

      I have to ask: why were you confident that the * and % operators work correctly? Did you even look at the code for them?

      Diffie's point is that, when you can see the algorithm, you have the _option_ to analyze, understand, and verify it.

      It's up to you to exercise the option, and most importantly, apply resources to that task appropriate to the risks you face.

      If you don't have the option to excercise, you just have to hope that the function provider applied the appropriate amount of _their_ resources to mitigate _your_ risk.

    9. Re:Open Source encryption tools by Anonymous Coward · · Score: 0
      The moral of the story? I suppose it's just this: the "many eyeballs" theory quickly breaks down in the face of esoteric algorithms.

      Maybe so, but speaking as a Professor of Mathematics, the lesson I prefer is that you can never learn too much math.

  27. "forgotten more about crypto than 99.9%" ? by YahoKa · · Score: 3, Informative

    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!

  28. Re:FP! ...anyway... by brejc8 · · Score: 2, Funny

    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.

    And he would tell us all about it if he had a mouth

  29. Re:FP! ...anyway... by griffjon · · Score: 1

    Wrong. S&L is the best book to give to your boss to get hir to understand why you want to devote a bit of time to securing your new product instead of releasing it as soon as it's semi-functional. S&L is not a very technical book (not like Applied at all), and parts are chapter-long advertisements for Bruce's new-at-the-time-of-publishing business, but but it can be appreciated even by marketdroids and pointyhairs.

    --
    Returned Peace Corps IT Volunteer
  30. 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"
    1. Re:Incongrous Thinking... by plugger · · Score: 1

      The vulnerability of a tyre blow-out WAS revealed by consumers. Unfortunately, it was revealed at the time their cars ran out of control. When enough incidents happened (or did it take the threat of court action?), the manufacturer was forced to act.

    2. Re:Incongrous Thinking... by IncohereD · · Score: 1

      Were the consumers given the plans ('source code') to the car and tires? Were they given as many copies as they want to run in different enviornments ('OSes', 'systems', 'platforms') as they wanted? It's not the same thing.

      The product was publicly available, but not the engineering ('algorithm') behind it.

    3. Re:Incongrous Thinking... by Anonymous Coward · · Score: 0

      Almost everyone doing serious development has
      probably fixed an opensource bug in their time..
      Where I previously worked, we've had people
      submit patches, bug reports and use workarounds
      for things like the linux kernel, openssl,
      glibc, erm.. you name it :)

      --
      Silvio

    4. Re:Incongrous Thinking... by enkidu · · Score: 2, Insightful
      Yeah, and due to the "open source" nature of the tires, consumers could FIX that "vulnerability" without waiting for Ford to issue "new tires". Think of what would have happened if the tires+wheels were bolted on with secret locked nuts unlockable only by Ford. All the Exploreres would have had to have been garaged until Ford modified the design of the tires and sent them to service centers where the Explorers would go to have new tires put on. This is essentially the deal with closed source security software.

      What happened instead was, as soon as consumers heard about the vulnerability, they had the option of patching it themselves, namely, going to Tires-R-Us and getting a new set of tires. The argument was not "study => security" but "secrecy != security" and "easy fix => security"

      EnkiduEOT

      --

      There is no trap so deadly as the trap you set for yourself
      -Raymond Chandler, The Long Goodbye
    5. Re:Incongrous Thinking... by bourne · · Score: 1

      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.

      Because it is taken as a given that the whether or not the organization has a qualified individual is completely moot if the source isn't available.

      If the source is closed, then you will never have a chance to audit the source for vulnerabilities. If the source is open, then you may or may not have a qualified person - but if the shit hits the fan, you can get one fast.

      Consider this: Your web farm uses (Apache or IIS). You find that someone with a 0day is able to compromise your servers; you quickly tweak your IDS so that you can detect and clean up after successful attacks, but until you get a patch you're just playing catch-up.

      Now: Given that you have the exploit on the wire, how hard is it for you to hire a contractor to find the bug, fix it, and get your ass off the griddle? How much time will it take? If you're using Apache? If you're using IIS? If you have to depend on Microsoft to do the looking and fixing for you?

      Even if you don't have a qualified person on staff who previously audited a code... now's a damn good time to have the source. Would it be better for the company to have audited it beforehand? Sure, but failing that, with the source you can bounce back from problems a lot faster.

    6. Re:Incongrous Thinking... by (rypto* · · Score: 1

      Incongruous ? or Incongrous ?

      --
      #3 pencils and quadrille pads.
    7. Re:Incongrous Thinking... by dracocat · · Score: 1

      I think the car analogy would work better with closed vs open source system crashes. Unless the tire problem gave rise to Ford break-ins.

    8. Re:Incongrous Thinking... by karlm · · Score: 1
      ... and I'm sure Firestone published their exact formulations for the rubber, as well as thermal and wear test data, as well as tensile and shear strengths of the ply material as well as the rubber-ply matrix.

      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.
      Most of these experts had access to only the "compiled tire", so they'd have to wear out a lot of tires doing testing to find the problem.

      The main problem with your analogy, however, is that I've never heard of a single person that formulates thier own rubber, weaves thier own plies, and manufacturers their own car tires as a hobby. However, there are many many people that make thier own computer software from scratch as a hobby and there's very little money to be made as a freelance tire analysis consultant. If you find a few esoteric bugs in software, you stand a much better chance of getting paid good money as a computer security consultant. Oh, and computers are much more common than tire manufacturing equipment in people's homes. The electricity cost of pulling up a text edditor, a compiler, and a debugger is much less than the cost of polyester, vinyl, and steel. Software is simply the ultimate in DIY, while tires are really hard to create and test yourself. (How many people do you know that have made a little extra money on the side selling car tires they made? How many people do you know that made a little extra money selling shareware?)

      --
      Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
  31. So many bugs by t_allardyce · · Score: 2, Insightful

    If microsoft opened up their all their software tonight. Tomorrow morning every windows server would be down, every internet-connected desktop would be down, Infact anything that could be down would be down. Open source software such as linux is probably on a higher level than closed source, so the majority of bugs that could be found in linux already have. For example, if you open fire randomly at a crowd with a machine gun, you'll hit more people in the first few seconds than in the next minute, because after you've taken out the bulk, what your left with is afew scattered people that are harder to pick off - anyone who plays fps's will know what i mean.

    --
    This comment does not represent the views or opinions of the user.
    1. Re:So many bugs by Anonymous Coward · · Score: 0
      In case you missed it, Win2K has higher security rating based on the Common Criteria then Trusted Solaris...


      I maintain some Redhat and Windows 2K server. I've had 9 Radhat patches THIS Year; none for MS...

      'nuf said

    2. Re:So many bugs by evilviper · · Score: 3, Funny

      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
    3. Re:So many bugs by scrytch · · Score: 1

      > If microsoft opened up their all their software tonight. Tomorrow morning every windows server would be down, every internet-connected desktop would be down, Infact anything that could be down would be down

      Complete utter nonsense. The administrator password on my machine is foofra. The IP address is 192.168.1.179

      What's that, you can't get to it?

      Oh yeah.

      --
      I've finally had it: until slashdot gets article moderation, I am not coming back.
    4. Re:So many bugs by OneStepFromElysium · · Score: 1

      And that's why you hide under the AC banner.

      Number of patches is a poor description of security. When exploits are discovered for RH, they are quite timely on issuing patches. When Win2k exploits are discovered, they often go unpatched for months, then one "mega"-patch is delivered.

      Congratulations on not having to patch your insecure win2k box.

  32. Finally... by fussman · · Score: 0

    ...an open source programmer who uses concepts that originate from outside of the whole world of programming/hacking/fragging.

    A secret that cannot be readily changed should be regarded as a vulnerability.

    --
    Support Israeli punk bands. Man Alive.
  33. The paradox of security by gentlewizard · · Score: 2, Insightful

    I forget who said this, but there's a real paradox with security that the more you THINK you have, the more risks you will take, and therefore the less safe you are. When you know you are vulnerable, it heightens the senses, focuses your awareness. You're sharper, because you have to be.

    I'm not saying throw the security away, but think about this: trusting on a secret can make you complacent just as Diffie writes. Knowing your code is Open Source and everyone can look at it should help you focus on the real problem, which is that security is a moving target and needs constant evaluation.

  34. car analogy in article by lars-o-matic · · Score: 2, Insightful

    I agree with WD's theme, but his defense of Open Source has a weak/irrelevant point.

    But all this does not mean that there is no group responsible for the car. At a level different from the mechanic, the manufacturer follows the repair history of each car model, then issues repair advisories and occasionally recalls a model for maintenance if a serious fault is found.

    I think auto-manufacturer responsibility is anchored in legal liability. If the wheels come off, the builder is sued, no matter whether the engineering diagrams are freely available to the car's owner.

    Moreover, just because a program is open-source software does not mean that no one is responsible for it.

    Yes, but it doesn't mean someone is. He's arguing in favour of a (legally liable) vendor.

    As noted by other posters, the basic arguments have been written in more detail by people like Bruce Schneier -- see his Cryptogram newsletters for some well-thought-out writing.

    A nice little article, suitable for sharing with less-technical coworkers.

    --
    je ne suis pas un fou
  35. 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 dentar · · Score: 1

      depends.. is the GET http://www.example.com/3458976394534/admin.html encrypted when going over the wire? If not, then it's LESS secure than a password. Usually the password would be encrypted in some fashion. If not, then they're equal.

      --
      -- I am. Therefore, I think!
    2. Re:To those who bang on that... by caluml · · Score: 2, Informative

      http://www.example.com/3458976394534/admin.html

      Yeah - and just wait until that gets into Google :) Google might spider a site with public proxy logs, and it gets in that way.

      Wait, that's given me an idea.... :)

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

    4. Re:To those who bang on that... by jafiwam · · Score: 1

      It is important to not confuse the scope of the whole idea (keeping X from being accessed) with method 'security' or method 'obscurity'.

      You can achieve security by using a password that is obscure, if your password is involved in a system of being changed frequently and being complicated enough to serve as a barrier. Just because the adjective 'obscure' is used, does not mean that keeping X private is done through obscurity.

      The password is obscure in that with only a handful of characters, in a user / pass PAIR, the obscurity of it (difficulty to brute force) can approach infinity. Which in turn is a secure method of preventing X from being accessed.

      If you follow the scope the article is talking about your example of the URL is obscurity, that there is no barrier to accessing X as long as you know in general where the holes are and that the URL exists. Remember any dorko with unsecured IIS could thwart some of the worm scripts just by not using the same path names the worm assumed were in place. (Don't put your idq files in the scripts directory! Duh!) Renaming folders without closing the hole made the obscurity of IIS install unique, only that one server has that pathname used, therefore a worm is ineffective against it. That is obscurity, but is still sure as heck is not secure, as anybody who knows the pathname can get right in.

      Though, I think the article missed something by not adding that security can be enhanced by obscurity, and obscurity can be enhanced by security. Using BOTH is the best way to keep the baddies from getting X. That's what the government does, only a few people know (obscure or secret) and those that do have to use security (password, fingerprint or whatever) to access information X.

      The problem is, to the uninitiated, obscurity looks like and seems just as good as security After all, who is going to guess that I wrote my PIN number on the other card! Rather than noting that the best way to keep a PIN number secure is to not use birthdates (be obscure) but also memorize it and not write it down (secure).

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

  37. open versus closed is not as simple by mikefocke · · Score: 2, Insightful

    OSS can be viewed by many eyes.

    But is it?

    Can you be sure that each and every code change is reviewed by competent individuals trained and experienced in security and with a comprehensive knowledge of the architectural issues with the work product? By each and every we include device drivers from every source under the sun that are in the kernel and thus have the ability to do good things or ill.

    Who maintains the security model, the design documents, the overall architecture? Who argues that this code, while it speeds things up wonderfully, violates architectural principles that are important to the security of the entire system? And who can make the decision stick...that security is more important than functionality or speed.

    Yes OSS could be more secure than most proprietary products by virtue of the quantity of eyes.

    But perhaps it is possible to make a product even more secure by following great developmental practices, ones that are only enforceable in a proprietary world. And submitting it to peer review by acknowledged experts.

    Compare the assurance requirements contained within the Common Criteria to the practices followed in most OSS product development and maintenance. OSS has some real problems.

    Not that it isn't wonderful ... but security in the OSS world has yet to be proven.

    1. Re:open versus closed is not as simple by Random+Walk · · Score: 1
      OSS can be viewed by many eyes. But is it?

      Depends very much on the popularity of an application. From my own experience, probably only the Top 500 (maybe the Top 1000) get enough feedback to maintain some level of quality.

      On the other hand, every day design flaws and bugs are found in some proprietary applications. The fact that in the 'proprietary world' you could enforce 'great developmental practices', apparently does not mean that it is really done.

      Furthermore, customers look for features, and certainly do not easily perceive the value of good design in the code they never see. Therefore, in the 'proprietary world' there is little (or no) incentive to follow 'great developmental practices', whatever these may be. If anywhere at all, I would expect good design in OSS where return on investment is much less of an issue sometimes.

    2. Re:open versus closed is not as simple by FreeUser · · Score: 1

      Not that it isn't wonderful ... but security in the OSS world has yet to be proven.

      This is only true in the strictest scientific sense, in that nothing is ever "proven", nor can it be. Not evolution (despite a mountain of evidence so high only the foolish with an agenda ignore it), not even gravity itself, something we all count on and take for granted every day. In science, nothing is ever "proven," and always open to question if new evidence arises.

      However, in the sense of having a "proven track record", the only context in which a discussion about security makes any sense, you are flat out wrong.

      Open source and free software apply the classic scientific method of open publication and wide peer review. Do errors sneak through? You bet, just as they do in science. But, just as in science, they are found at some point and corrected, because they can be reviewed and eventually will be. Contrast the success of chemistry versus old school alchemy, a system based on secret formulas and closed procedures, and you get a very real sense of the advantages of free software and open source versus proprietary software.

      Or, simply contrast the security of Microsoft Windows versus OS X (a proprietary system built upon the framework of a an open system, namely FreeBSD), FreeBSD itself, and GNU/Linux. None are perfect, but only one has a dismal and provenly horrible track record (Windows), while the other three have proven and quite strong, though naturally imperfect, track records.

      You make a number of reasonable points ("Can you be sure that each and every code change is reviewed by competent individuals trained and experienced in security and with a comprehensive knowledge of the architectural issues with the work product?") and intersperse it with a great deal of FUD (e.g. "following great developmental practices, ones that are only enforceable in a proprietary world...", something which really doesn't exist). One of the features of free software is that it can follow any proprietary design and development practice it wishes (don't like what the current team is doing? Fork the code and develop it in house using whatever proprietary methodology you like. Under the GPL you can even use the result and not share, so long as you keep it in house. Distribute it and you must distribute the code, but that in no way restricts or limits your development, design or implementation methodologies). The entire gamut of proprietary software development methodologies are available to free software, if free software developers wish to use them. However, the corallary doesn't apply: proprietary development methods are largely cut off from many of the proven methods inherent in free software design, not least of which is scientific peer review. Not by a few hand chosen experts, but by anyone with the knowledge and desire to test the results. Science has been conducted very successfully using this method for centuries, while the closed methods (limited or no review, "valuable-secrets" bearing a closer resemblance to old world alchemy than modern science) have been proven again and again to be seriously flawed.

      Indeed even your "can you be sure" question is a bit disingenuous ... as no one can ever be sure that another has done anything related to the code, indeed, even security certifications don't give you that kind of assurance. One thing we can be certain of, whether we're discussing the notorious and well documented lack of security in Microsoft's proprietary products, or the glacial slowness with which Sun Microsystems would address security holes in Sun OS prior to their being announced in BugTraq, is that, based upon the historical record, open source and free software are vastly more responsive to addressing security concerns when they arise, and that they are, for whatever reason, quite a bit less vulnerable than their proprietary counterparts to attack. Most reasonable people look at these facts (e.g. IIS is cracked much more often, and is vastly more vulnerable to worms, than Apache is, despite Apache's greater popularity and wider deployment on the web), and even when personal knowledge is lacking apply occams razer in attributing the likely cause of free software's superior security to the much wider exposure and perusal its code gets, vs. that of it less secure, proprietary counterparts. There are some, with an agenda to push, who will argue that it is the popularity of the less widely deployed IIS, rather than Apache's superior, open design and implimentation, that is responsible for this disparity, but those looking in from outside generally find such arguments quite laughable, and rightly so.

      In any event, whether or not I can be absolutely certain someone competent has audited a particular line of code, I can be very certain that the liklihood of a line of free code having been looked over and even audited at least once, perhaps many times, is much, much greater than the liklihood of a similiar line of proprietary code having been so examined. And in a world where certaintly is inherently impossible, that probability is all we have, and that probability quite dramatically favors open source and free software.

      --
      The Future of Human Evolution: Autonomy
    3. Re:open versus closed is not as simple by Anonymous Coward · · Score: 0
      holy shit man, do you live in slashdot or something? you must have spent half your day writing this piece of drivel.

      here's a helpful hint. turn off the computer and go outside for once. arguing on slashdot is not good for your health.

      in short, get a fucking life.

    4. Re:open versus closed is not as simple by Anonymous Coward · · Score: 0

      Very good writeup. Well written and argued.

      (In other words, MOD THIS UP!)

  38. VERY WEAK ARTICLE by huckda · · Score: 3, Insightful

    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
    1. Re:VERY WEAK ARTICLE by alpharoid · · Score: 1
      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?'
      Yep. I respect Mr. Diffie and still rely on part of his work (as most of us do), but this article is useless.

      It would have made a great high school term paper, though.
  39. Passwords by Virtex · · Score: 4, Insightful

    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.
    1. Re:Passwords by rusty0101 · · Score: 1

      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.

      Sorry, I can't buy the argument that this is "...priced out of the range of individuals...". There are free and low cost systems available that provide this type of security.

      All a SecureID card is is a one way hash of the date and time along with the serial number of the SecureID card.

      The back end is a Kerberose style system that validates the authenticity of the card, verifies that it belongs to you, and lets the system you are logging into know what rights you have at this time.

      This can be done with PAM and plugins that provide the appropriate features, as well as authentication module that works off of a similar function.

      As a result of the fact that two clocks rarely maintain syncronicity over long periods of time, the back end authentication system generates hashes for one or two minutes around the current minute. (hashing down to the second would be useless as most of these systems require manual entry of the hash value.) If matches are regularly found to be offset by one or two minutes over some period of time the back end starts adjusting the time tossed into the hash tree to reflect the drift relative to the mobile card.

      Building a software based system for this would be fairly simple, and in-expensive. Building hardware based versions would not be particularly difficult either, and if you are going to build them in bulk would be very inexpensive as well.

      Of course even with this level of security you will want to use passwords and or passphrases in some combination to deal with the prospect of someone walking off with your MobilKey.

      Good luck.

      -Rusty

      --
      You never know...
  40. 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
    1. Re:Nope. by naasking · · Score: 1

      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.

      So in other words, locking down the system is a URL change away, which exactly parallels the password situation. In fact, if you do it right (cryptographically secure random hash strings), a URL is more secure than a password. A secure scheme: an encryption layer so it's impossible to snoop the URLs, (at least) 128-bit crypto-secure URLs and you have yourself a capability-secure system.

      See these for more info on capability-based security:
      E rights
      EROS

      Discovering the URL is not trivial if you do it right. It becomes a problem of guessing a 128-bit string, or cracking the connection encryption keys. MUCH more secure than passwords which are typically no longer than 64-bits and alpha-numeric limited (effectively limiting them to around 32-bits - much less if you factor in how much people use english words).

    2. Re:Nope. by evilviper · · Score: 1
      Your DVD analogy is horrible:

      That security system hinged on keeping something secret.

      What system doesn't? Be it your private key, or your password, you are screwed if someone gets a hold of it. What CSS did wrong was to make their system easy to break in a short time... A longer key, more keys, or anything similar would have accomplished their goal.

      Secrets, as part of a security system, are BAD.

      You are absolutely correct. In order to secure your system, I ask that you please post all of your passwords here.

      If they cannot be changed quickly, they render you more vulnerable than if they were out in the open to begin with.

      So it would have been more dificult to copy a DVD with no protection, than an encrypted one once CSS was cracked?

      It's very clear that you are not clear on the concept of obfustication verses real security. What really bothers me is the fact that you were moderated up despite that very clear fact.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  41. Credit cards by binaryDigit · · Score: 1

    The secret to strong security: less reliance on secrets

    The "funny"/scary thing is that the majority of credit card usage/processing falls under this statement.

    Think about it. People shred there cc receipts, they demand secure links to ecommerce sites, they shroud their credit cards and SSN's from prying eyes. Yet, you hand your CC to Joe Sixpack at the gas station or the waitress at the restaurant. I remember back in the day when I worked at a service station, I relized back then that I could simply collect peoples CC#'s and use them surreptitiously. Yes there are more safeguards now, but it still is simple to do. Anyone who thinks that their CC is truely secure is fooling themselves.

    So what you do is to make reasonable efforts to keep things secure, but ALWAYS check your statements, and be ready to act if something happens.

    1. Re:Credit cards by Anonymous Coward · · Score: 0, Flamebait

      OK Well you're a nerd, and you probably don't even have a credit card, my credit card is 100% safe because I maxed it out and now it's in the freezer in a 4 pound block of ice you ass, now, stop being such a prick and amdit that i am not fooling myself

      you moron
      worthless moron!

    2. Re:Credit cards by Alcohol+Fueled · · Score: 1
      "Think about it. People shred there cc receipts, they demand secure links to ecommerce sites, they shroud their credit cards and SSN's from prying eyes. Yet, you hand your CC to Joe Sixpack at the gas station or the waitress at the restaurant."

      I think that has to do with the situation. When using your credit card online, the number is stored in a database on a server (usually), which has the possibility of being hacked. People hand their credit cards over to Joe Sixpack or the waitress because they are actually there, and you can see what they do with your credit card, thus I think people feel more secure since they can see who handles their credit card, and what's being done with it.

      --
      Ah am not a crook! (\(-__-)/)
    3. Re:Credit cards by Helmholtz+Coil · · Score: 1

      You're right-it was only a few weeks ago a friend of mine had a similar thing happen to them, although for him it was a debit card. Apparently the gas station had a little gizmo between the card swiper and the actual debit card unit, so that when the victim swipes their card it keeps a local copy of the info. By the time he got home they'd taken more than two thousand from his account.

    4. Re:Credit cards by binaryDigit · · Score: 1

      People hand their credit cards over to Joe Sixpack or the waitress because they are actually there, and you can see what they do with your credit card, thus I think people feel more secure since they can see who handles their credit card, and what's being done with it.

      And that's the scary part. Fact is that you don't see exactly what their doing. They take your card and disappear for several minutes, more than enough time to jot down the number/name (or simply save off the receipt) and also copy that 3 digit check code that everyone wants nowadays. Not too hard at that point to look the person up in the phone book to get their address, which is most likely their billing address, and then start charging. Now you may not be able to get things shipped, but you can certainly charge for services without a problem.

      Oh and I forgot to mention the issue with students. Any student is completely hosed when it comes to security since your SSN is almost always used everywhere. I would assume that identity theft amongst students is rampant.

    5. Re:Credit cards by JimBobJoe · · Score: 1

      Credit Card fraud, even Credit card fraud online, is dropping, so there is good news (check both visa.com and mastercard.com and see their security/fraud info for proof of this.)

      Having the numbers embossed on the front of the card is simultaneously a relic and a backup for when the hypercom goes down and the merchant has to run the credit card on the little swipe machine thinger.

      But if we didn't need that, or perhaps in the future Visa/MC will just decide to remove the embossed numbers, or part of the numbers (or better yet, you have a credit card you use with merchants that have no embossed numbers...and then you have one at home with embossed numbers for when you are ordering stuff online and need to know the number.)

      As for the form of fraud when they swipe the card through another reader to capture the numbers, other than an encryption system, which I don't have much faith in at this scale, that's what fraud protection is for. :-)

  42. Re:FP! ...anyway... by MmmmAqua · · Score: 3, Insightful

    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!
  43. All your secrets are belong to us by Skapare · · Score: 1

    If your secret (private key) becomes known, sure you now have the cost of creating a new key, revoking your old key, and making sure the trusted depository has both. Also, this does not eliminate some risks in others having trusted documents signed with your old key by your nemesis during the interim (or by those who fail to verify the key has not been revoked). But this cost is nowhere near the cost of designing a replacement algorithm were it the case we were using one which depended on secrecy to avoid being compromized. Not only would there be that cost of redesigning, but also the cost of having no reliable system in the interim. Instead, just one entity (you, if your secret key gets out) incurs the costs. This is also why keys should come with a set expiration date, so that those who trust them won't extend their trust too far.

    It's 2003. Have you changed all your passwords, yet? Have you created new SSH keys and removed all trust of the old ones?

    --
    now we need to go OSS in diesel cars
    1. Re:All your secrets are belong to us by KDan · · Score: 1

      Everyone, thanks for your responses. They have made me realise the importance, when designing anything that attempts to use public key crypto as an authentication/signature method, of providing a good and workable mechanism for updating the keys in other people's caches.

      Daniel

      --
      Carpe Diem
  44. FIRST POST THAT IS IN THE 100 RANGE FOR THIS TOPIC by Anonymous Coward · · Score: 0

    ALRIGHT! That was post #100 for this topic, meaning I am the ultimate first poster, the first poster firster, the only poster first, and i am hell of a lot sexy =er than you.

  45. My take on it by El+Volio · · Score: 1

    I wrote up my view of the article and posted it earlier. I think that (for obvious reasons) he tends to view things from a cryptography perspective and tends to miss what really happens "on the ground", but hopefully his voice will be influential in such matters among his colleagues.

    --

    "You can never have too many elephants on your team."

  46. Sun != OSS by Anonymous Coward · · Score: 0

    If OSS is so great, why does the bloke work at Sun? :-)

  47. Re:FP! ...anyway... by ssimpson · · Score: 3, Informative

    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."
  48. Secrecy by nuggz · · Score: 1

    Okay, I'll bite.

    I shred all personal documents (and junk mail and crap) to make it more difficult if someone wanted my personal information. It isn't foolproof, but it doe smake me a harder target, which is all I want.
    (Two men are in the woods, they run into an enraged bear, one of them takes off running, the other says "what are you doing, you can't outrun the bear". The first replies "The bear? I only have to outrun you")

    Secondly anyone can copy my CC number, you just need to look at the card, perhaps take a picture. I rely on the fraud protection to protect me.

    It isn't perfect, or even secure, but I think if I put enough barriers up, it might just be troublesome enough for people to avoid.

    1. Re:Secrecy by binaryDigit · · Score: 1

      I wasen't saying that you shouldn't do those things, only that people get a false sense of security doing those things. It's the "I have a $500 lock on my front door and a $.50 lock on my windows" thing. I shred to (have two shredders, one strip for most stuff, one cross cut for "important" stuff), but I religiously check my statements because I know that there are many other points of weakness.

    2. Re:Secrecy by An+Ominous+Coward · · Score: 1

      Of course, running will trigger the bear's hunter/prey instincts. Let that one guy take off, the bear will almost certainly go after him.

  49. Extending the Analogy by core+plexus · · Score: 2
    Stimulating article, if a bit short. However, and not to try and sharpshoot him, but I feel there is one inportant part missing. He writes: "Look at it this way: A mechanic who checks your brakes is acting to ensure the correct functioning of a system essential to your security.

    To which I would add: I regularly check my brake fluids (and other stuff). However, most people I have seen who are not pilots don't even do a walk-around of their vehicles, they just jump in and go. Certainly I am not proposing each user become a "mechanic", but some basic training would go a long way.

    This little penguin doesn't forget favors

  50. Two words... by Anonymous Coward · · Score: 0

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

    Poison Steak.

    1. Re:Two words... by Anonymous Coward · · Score: 0

      It's not poison... they're just sleeping, Governor!

  51. Re:IN LIGHTY OF RECENSET EVENTS by Xerithane · · Score: 1

    PLEASE someobdy jsut ban wait let me restart please somebody just ban this whole damn city from slashdot!

    Wow, I didn't know Jeff K. posted on slashdot.

    --
    Dacels Jewelers can't be trusted.
  52. That's OK by Anonymous Coward · · Score: 1, Funny

    Every seen how much steak it takes to bribe a Rottweiler? It's gonna cost you an arm and a leg ;)

    That's OK as long as it isn't my arm and leg!

  53. Mod this up... by Anonymous Coward · · Score: 0

    I have more confidence in SSL-enabled web sites than I do using my card at places like restaurants where exactly that kind of compromise can happen. I have a fair amount of confidence that the first time I got a monster fraudulent charge on my card it was compromised at a restaurant. The card was a VISA check card which had not ever been used on the Internet to order anything. Since it snarfed money directly from my checking account, I was in deep shit. Lousy bumfucker got a plane ticket to Miami on my dime. At least it was easily reversed...too bad about those NSF charges it generated...

  54. This article assumes closed source is for security by weld · · Score: 1
    I think it is a faulty assumption to say that closed source vendors are not publishing code because it would lower security. Closed source vendors were not publishing code long before security became an issue. They don't publish the source because they do not want others to replicate or interface with their technology easily.


    Obscurity can help a systems security but it cannot be relied upon. Diffie knows this. This is why NSA does not publish the crypto algorithms that they use. They certainly don't rely on this obscurity however.


    Running SSH on a non-standard port is obscurity. It does not replace keeping up to date on patches. It can however help keep your system from being compromized if a fast moving SSH worm were to take off. It will give a bit of time to get the patch in place.


    Any piece of software will benefit from a dedicated security audit whether it is closed or open source. If we want software to be more secure we should be demanding that publishers audit the code before foisting it out on the world whether open or closed source. If all closed source vendors actually did this and fixed the problems there is no doubt in my mind that closed source software would be more secure. I am not holding my breath however.


    -weld

  55. defender of all that is open by clarionhaze · · Score: 1

    i'm glad to see he somewhat, as i read it, defends open source. as a 19 year old just getting started with web development one of my worries has been convincing potential clients that php is not less secure than asp. sometimes it's hard to explain the benefits to those who don't understand. hopefully this article will be a good tool for me to use.

    --
    all i see are 1's and 0's
  56. Diffie is a screenwriter too? by dagnabit · · Score: 1

    Hey, he must have come up with the premise for 'Sneakers' also -- "too many secrets"!!

  57. Pretty Low-brow by Shamanin · · Score: 1

    considering the guy co-wrote one of the most important cryptographic algorithms used in most key exchanges.

    --
    come on fhqwhgads
  58. I'mma gonna by Anonymous Coward · · Score: 0

    try a couple of Pit Bull's on em.

  59. Re:FP! ...anyway... by Anonymous Coward · · Score: 0

    I have a friend who used to work at Counterpane, and let me tell you this all sounds good on paper,
    but in real life security is much harder to achieve. The crypto math is rarely the weak point.

    My friend related stories about times he discovered a customer that had been hacked months after
    the original attack. Since Counterpane didn't alert them right away (like the contract called for),
    they just didn't tell them unless they saw further intrusions. Not only that, but there were numerous cases
    where one companies security alert was sent to a different company.

    The bottom line is that people will almost always be less secure than the crypto math.

  60. Obligatory Simpsons Reference by uberdave · · Score: 1

    "These weiners will give me the quick energy I need to escape!" - H. Simpson

  61. Building Secure Software by prankster · · Score: 1

    Schneier's Secrets & Lies is indeed excellent.

    For another excellent but more technical book on security I would recommend Building Secure Software.

    Building Secure Software has a foreward by Schneier in which he writes: "Read it; learn from it. And then put its lessons into practise."

    Chapter 4 in the book is "On Open Source and Closed Source".

    A most own book if you are interested in software security.

    1. Re:Building Secure Software by Anthony · · Score: 1

      Thanks for the reference. The table of contents of the book look good. I had just decided last night to put together an in-house talk on "Free Software: is it safe?". I planned to take a even-handed approach to it and this book looks like it addresses a lot of the issues.

      --
      Slashdot: Where nerds gather to pool their ignorance
  62. Shared Secret by emarkp · · Score: 2, Informative

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

  63. Ahem...budget? by spells · · Score: 1
    If anyone has both the right and the need to study the code and be assured of its correct functioning, it is users. In fact, auditing the programs on which an enterprise depends for its own security is a natural function of the enterprise's own information-security organization.

    Unfortunately this sounds like an argument AGAINST open source in the enterprise. How much money should an enterprise budget to audit each open source program, including patches, etc? Who would approve that budget when closed source programs come "pre-audited" in the eyes of the PHB?

  64. Crypto if Factoring is Solved by billstewart · · Score: 1
    Factoring and Discrete Log appear to be hard problems, but if somebody is able to get a Shor-type quantum computer with enough resolution to crack practical key sizes, we could lose them. But we're not back to square one if that happens. Not only do we know a lot more crypto math than a few years ago, but there are still cryptosystems that QC doesn't solve, such as most symmetric-key systems (or at most, it cuts the effective keysize in half, so you go use triple-AES or whatever.)

    There are Key Distribution System approaches using symmetric keys, such as Kerberos, that we'll have to remember how to do if this happens. They're not as nice as public-key, and I'm not aware of any digital signature systems using them (which is a big lose), but they can still provide privacy.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  65. Re:FP! ...anyway... by MmmmAqua · · Score: 1

    Thanks for the pointer. I'll be sure to read Dr. Anderson's book next.

    I'm looking forward to Schneier's next one, as well.

    --
    Arr! The laws of physics be a harsh mistress!
  66. And M$ has to keep their source secret by Anonymous Coward · · Score: 0
    To protect "national security"?

    Why does reading this article with that in mind give me the willies?

  67. This probably isn't how legal signing is done by sleepingsquirrel · · Score: 1
    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.

    Hmmm...that works for the patch repository, but I'm not sure it's perfect for the legal situation. Let's say Alice wants to get out of a digital contract with Bob, she merely has to state that her key was compromised _before_ the notary's time stamp. But I'll bet that someone has already come up with a better contract signing algorithm.

    1. Re:This probably isn't how legal signing is done by pclminion · · Score: 1
      Hmmm...that works for the patch repository, but I'm not sure it's perfect for the legal situation. Let's say Alice wants to get out of a digital contract with Bob, she merely has to state that her key was compromised _before_ the notary's time stamp. But I'll bet that someone has already come up with a better contract signing algorithm.

      Yes, they are called confirmation/disavowal algorithms. There are several methods by which you can securely "disavow" (disclaim authorship of) a signed document.

      Search Google for the term "cryptographic disavowal."

  68. liability by KjetilK · · Score: 1
    Actually, that's (one of the reasons) why I argue that having liability for the software you sell would be a Good Thing[tm] for Free Software.

    First, I said "for software you sell", which means, it is not the individual developers who are liable, liability follows the money. Distro-makers would be liable for the product they sell. As well, of course, as vendors of proprietary software.

    Liability would mean that the distro-makers actually get a product, they sell a warranty, and that warranty would mean that they would have to more carefully audit the code of the software they sell. Thus, they could ask higher prizes, then they could afford to employ more hackers to audit the code. Net result, we all gain, because the code that makes it into commercial distros gets more professional attention.

    Also, since we all know that Free Software is better from the outset than proprietary counterparts, we would get a head start, and M$ would spiral down as they get hit with big law-suits... ;-)

    --
    Employee of Inrupt, Project Release Manager and Community Manager for Solid
    1. Re:liability by oliverthered · · Score: 1

      It could also be a good argument for not documenting code.
      I found 2 bugs in the USB layer because the documentation was poor, so I had to go through the code and find out what was going on.

      also I now more about USB then I would care to, and have a fair knowlage of the inner workings of USB on linux.

      --
      thank God the internet isn't a human right.
  69. Re:FP! ...anyway... by jhoffoss · · Score: 1

    Actually, The January '03 CryptoGram (mailed out yesterday) has an article discussing AES, RMAC and 3DES discussing how "secure" it is, and in reality, why it is not secure. Check it here.

    --
    Linux: The world's best text-adventure game.
  70. Re:FP! ...anyway... by roady · · Score: 1

    I second that. Security Engineering is the best and most entertaining security book that I have ever read.

  71. NSA , DVDCSS,and Hardware Crypto by billstewart · · Score: 1
    The extreme case of binary-only is hardware-embedded crypto. It's definitely harder for Bad Guys to crack, since software leaves all their bits out in the open waiting for you to run them under a debugger, while hardware modules often don't let you see much of the internals, and can sometimes arrange to trash themselves if opened. The big use of them in the US was the NSA providing them to the military; back before we had good crypto, there were a lot of probably simplistic algorithms that depended on hardware-provided obscurity to be secure.

    Aside from covering up weak design, and providing higher performance back when that was still a limitation of general-purpose hardware, there actually are good reasons for hardware crypto. The primary one is key protection - software systems make it too easy to leak keys, and whether you're using persistent keys of some sort for identity and authentication or only using Diffie-Hellman key exchange to create transient keys, you still need to protect them during a session.

    One way to look at binary-only software is that it's really just bad documentation; source code is much better documentation. It's unable to keep secret keys secret, and as demonstrated a couple of years ago, there's no guarantee that some 15-year-old kid won't figure out how to use your code as well as revealing how lame it is :-)

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  72. What's more important than a great article: by EEgopher · · Score: 1

    Is that the Chief of Staff of Sun Microsystems has hippie-hair and an unkempt beard.

    --
    hi, I like pancakes -.-- -.-- --..
  73. Validity for secret keys by billstewart · · Score: 1
    I disagree on a couple of points
    • For a given application, there's a length of time that you need to have a valid signature. Maybe it's "forever", or just your lifetime, or the length of time that a contract is valid, or the appropriate Statute of Limitations for fraud, but it's a usage-dependent issue, not a technical issue.
    • The corresponding technical issue is whether your signature system, and the operational environment around it, is strong enough to protect it that long. It's easier if you use a strong algorithm with enough key bits to prevent cracking during the lifetime of the planet, but you've still got key protection to worry about.
    • Once your key is known to be compromised, then obviously future signings are known not to be trustable, but this leaves two big problems - how to tell when the key was compromised, and how to tell when a signature was made. If you know that the signature wasn't compromised until your laptop was stolen, or your business partner left your firm, that's one thing, but it's often harder to be sure. But more importantly, a signature doesn't usually have a trustable timestamp on it, so without some additional mechanism for dating the signing event, or a problem space where old signatures aren't interesting, it's hard to tell whether a signature was made before or after the compromise, because the person who used the leaked key to forge the document might have also forged the date on the document. (There are applications like signing Diffie-Hellman keyparts when setting up a secure phone call where you don't care about old signatures on documents, you just care about right now.)
    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  74. test please ignore by billstewart · · Score: 1

    hey, where's my karma bonus?

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
    1. Re:test please ignore by billstewart · · Score: 1

      another test, without checking the little box

      --

      Bill Stewart
      New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
    2. Re:test please ignore by Anonymous Coward · · Score: 0
      You'll never find me!

      ././.,./.,.,. A. Coward

  75. Word Processor Encryption and other apps by billstewart · · Score: 1
    There _are_ lots of people who will insist that their secret proprietary algorithm is more secure, but most of them are obviously selling snake oil.

    The more serious problem is applications from major software vendors that include passwords or other security features that aren't secure, and are closed-source not to protect the crypto, but just because they're proprietary applications. A couple of obvious examples are A Popular Word Processor from a Large Company in the Northwest and Several ZIP archivers that have passwords and Microsoft's initial PPTP products which totally botched their use of RC4 and had several other serious bugs.

    A somewhat different example is RSA's trade-secret-limited sale of the RC4 algorithm and implementations of it. That wasn't kept secret to protect it against crackers, it was kept secret so they could charge money for toolkits instead of people implementing the algorithm themselves, possibly more successfully than patent licensing on RSa public-key had been, and the reason to believe it was secure was that it was written by Ron Rivest and checked by his coworkers, who are one of the few groups with enough credibility to get away with such an otherwise-dodgy approach. (The NSA and KGB can also, but besides having a repuration, they've also got a captive audience...)

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  76. Whitfield Diffie by Banjonardo · · Score: 1

    For all of you who read Steven Levy's Hackers, you should remember who he is. Levy devotes chapters and chapters to him.

    --

    -----

    Score 3? For what? Being wrong, at length? - smirkleton

  77. Hack the secret government by rufusdufus · · Score: 1

    The US government has a lot of secrets. Whole agencies even existence have been secrets for decades (like the NSA); how many do we not know about today? And there's the secret black budget written by congress.

    Imagine a middleman attack on this system.

    Your forge up some fancy documents, then go recruit some people to your secret organization. Ostensibly, you are a secret arm of the TLA, a super-secret black-op, so they have to be discrete. You then have those employees recruit more people for you.
    If you do it right, you will soon have a large organization made up of people who believe they are working for a secret national security agency willing to do just about anything because they are patriots. This will take money, but given that you are a black-op, nobody can track your finances, which most likely come from clever schemes where your 'agents' unwittingly secure loot for you to buy more agents. All in the name of national security, so you never have to explain yourself. If one of your recruits gets caught doing the bad thing, they will have been trained to keep mum, and since you operate like a real black-op, you won't be easily rooted out. If you trained your first recruits well, most people in your 'agency' won't even know you exist.

    Anyway, if you use your imagination a little bit you might be able to scare yourself.

    Could this work? Is anyone so stupid to fall for it? Sadly, yes. There are a lot of gullible people in the world. A close aquaintance of mine believes to this day that the FAA is really a secret organization with assassins, aircraft navigation VORTACS are black op bases that somehow shoot down soviet nuclear missles. She actually thinks she was a secret agent doing missions for the FAA. She won't tell me what she did, but implications are that the people she 'worked' did some really nasty deeds.

  78. Re:FP! ...anyway... by Simon+Garlick · · Score: 1

    I hasten to point out that the article was a criticism of RMAC. Just in case someone skimmed the parent post and promptly had a breakdown, thinking that 3DES was no longer The Mack.

  79. Security Through Obscurity has its place by lildogie · · Score: 1

    > ... "Security through Obscurity" is useless.

    I agree that Security Through Obscurity is far, far from adequate, but it is not useless. It can be useful as part of a security scheme that depends on other, stronger defenses.

    The less the opponents know about you, the tougher it is for them to recognize your vulnerabilities.

    And there are _always_ vulnerabilities.

  80. It's sad... by Alex+Belits · · Score: 1

    ...that cryptographers and mathematicians still have to remind people the most basic things about security. It's especially sad that they have to remind those things to programmers.

    --
    Contrary to the popular belief, there indeed is no God.
  81. I hacked you in 5 seconds by freeweed · · Score: 1

    I connected up to your IP, but all I found was this folder full of fake Olsen Twins porn... :(

    --
    Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
    1. Re:I hacked you in 5 seconds by Anonymous Coward · · Score: 0

      ..you do realize what you're implying.

    2. Re:I hacked you in 5 seconds by zapfie · · Score: 1

      127.0.0.1 is the same as localhost.. it's whatever machine you are currently on..

      --
      slashdot!=valid HTML
  82. Show Offs on Slashdot by killajews · · Score: 0

    I don't know why people try to show off by saying one or two facts on basic crypto stuff like simple PK algorithm like RSA. Are you trying to show off that you are smart? More like triyng to show off your ineptness since half of the posts written by these show offs don't know what the hell they are talking about.

  83. Re:oh plz by CableModemSniper · · Score: 1

    Ransom Love?

    --
    Why not fork?
  84. URL can be as secure by r6144 · · Score: 1

    http://www.example.com/3458976394534/admin.html

    If you are sure you don't have any web proxies in your way, and your browser doesn't show or store the URL in any way (history, bookmarks, cache, etc.), then it is probably as secure as a clear-text HTTP password --- it only leaks to packet sniffers.

    The problem is that it is hard to make sure that your software and web proxies don't do the wrong thing, because all software know that HTTP password should be secret and not be logged or stored in cleartext, but noone knows a URL should also be secret!

  85. A definite *must read*??? by yulek · · Score: 1

    okay, the guy is a genius, but this article doesn't say anything new nor does it prove anything.

    we all know security through obfuscation (or secret) is always going to have a hole.

    guess what, passwords, password phrases, keys, certs, they're all secrets too. i don't know of any security protocol/technology that doesn't involve some sort of secret be it your fingerprint, a password, a changing code on a keycard, etc. all we can do is make the secrets as difficult as possible to discover.

    Offtopic rant:

    why must even diffe resolve to the always inapplicable but ever present automobile-software analogy?

    what everyone seems to forget is that someone has to build the cars, it takes a lot of money to build them, and they are also easy to sell because you can't easily build one yourself, thus you have to buy one.

    comparing automobiles to software code is therefore ludicrous. just because you have all the plans for a car doesn't mean you can build one. however having all the code to a piece of software certainly does mean so.

    End of Offtopic Rant

    --
    in this age of communication i'm just not getting through
  86. SUKKKKKKK by Anonymous Coward · · Score: 0

    FAWKKKKK