Slashdot Mirror

← Back to Stories (view on slashdot.org)

GnuPG's ElGamal Signing Keys Compromised

Posted by michael on from the oopsie dept.

KjetilK writes "Werner Koch just sent an announcement saying that there is a severe bug in GnuPG >= 1.0.2 that makes it easy to compromise ElGamal keys used for signing. Note that such keys are not generated by GnuPG's standard setup, and should be relatively rare. Among the 850 public keys in my personal keyring, there were only one such public key (and a few subkeys). There is already a patch available to disable these keys."

12 of 144 comments (clear)

  1. Re:Conspiracy theory by adrianbaugh · · Score: 4, Insightful

    "Old" in cryptography is generally good. It takes time for crypto systems to prove themselves in the wild (regardless of how wonderful they might be in practice). Witness the continued popularity of 3DES. I'd much rather use a well-understood 30-year-old algorithm than some young upstart algorithm that may well still have vulnerabilities.

    --
    "'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
    - JRR Tolkien.
  2. Security and Complexity by fmaxwell · · Score: 2, Insightful

    Note that such keys are not generated by GnuPG's standard setup, and should be relatively rare.

    This is a very good example of insecurity through complexity. Increasing the complexity of encryption software through the inclusion of multiple, unnecessary key types is a good way to increase the odds of introducing a bug. If there were only 850 of those keys, then why was that "feature" included?

    This is the same thing that Microsoft does. Drastically increase the complexity of the software beyond what is necessary through the inclusion of unnecessary features and introduce bugs in the process. If this had been "MicrosoftPG" rather than "GnuPG", there would be an outcry on Slashdot about how stupid Microsoft is.

    1. Re:Security and Complexity by Anonymous Coward · · Score: 1, Insightful

      Yes, it is the same thing as MS does, but not the way you put.

      MS has a huge chunk of the market share: When a security flaw is found, the majority of the computers are hit.

      If there were more diversion, we wouldn't have so many problems.

    2. Re:Security and Complexity by fmaxwell · · Score: 2, Insightful

      This was an experimental setting to begin with, and the fact that it is included in the base GPG code doesn't affect the people using the standard settings.

      Have you ever heard the term "beta"? If a feature is not well-tested, then it should not be in the base code.

      As long as the experimental or rarely used code is kept separate from the rest of the program, the only problem is the extra source code you have to download and the extra binary size (if there's no option to #ifdef those sections out).

      Most people don't compile their own executables. Period. They don't know how to use #ifdef switches. They don't edit source code. I don't care whether you like it, whether you think that their priorities should be the same as yours, etc. It doesn't change reality. Something as important as encryption should not be released with "experimental" code in it.

      You also miss the other problem. More code is more room for exploits. What's to say that there could not be a buffer overrun exploit that's a part of some rarely used, minimally tested part of the code? That's where many such exploits originate.

    3. Re:Security and Complexity by fmaxwell · · Score: 3, Insightful

      Wrong. This has nothing to do with complexity, but with choise. It is good that there are alternatives to choose from. If there is only one option, one bug will affect everything and everybody. So having a choise is good.

      Then I hope that some seldom-used "choice" in your OS turns out to have a root exploit associated with it. Then you can tell me how great choice is.

      Choice is not good in encryption. Strength is. I don't want an encryption program that lets me choose between 15 types of keys, some of which are poorly tested. I want to select the key size and that's it. I want the algorithm to be tested to death. I want the implementation pounded on for man-years before I use it. I don't want to find out that the "choice" I made for a key type is something that 0.04% of people chose and that, because of its rarity, it had an undiscovered flaw.

      For security to work, it has to be adopted. Make it too complex, and it doesn't get adopted. PGP is a damned good example. Had it been simpler to use, every piece of mail you got would be signed and encrypted. But because of its complexity, it was only adopted by a tiny minority of users. You can't PGP-encrypt your e-mail by default because 99% of people can't decrypt it.

    4. Re:Security and Complexity by anthony_dipierro · · Score: 2, Insightful

      Have you ever heard the term "beta"? If a feature is not well-tested, then it should not be in the base code.

      So experimental drivers should not be included in the linux kernel?

      Most people don't compile their own executables. Period.

      And that's a good reason why the standard binaries should include as many features as possible, regardless of whether or not those features are experimental, so long as the inclusion of those features does not affect the program when they are not used.

      Something as important as encryption should not be released with "experimental" code in it.

      This wasn't so much experimental code as it was an experimental feature. The code worked fine. It was the algorithm itself which was exploited.

      What's to say that there could not be a buffer overrun exploit that's a part of some rarely used, minimally tested part of the code?

      Unless the binary is set up as setuid or setgid, that's irrelevant. The user running the program using experimental options is taking the risk that there might be such an exploit.

  3. Re:You have... by duncanmacvicar · · Score: 2, Insightful

    we just have to wait now for pleople to start using encryption and signatures... (to have somebody to scare)

  4. Open v. Closed by sanctimonius+hypocrt · · Score: 5, Insightful
    Here's an important point. At the end of the email, Werner Koch writes:
    Thanks ====== Phong Nguyen [4] analyzed the implementation of GnuPG's cryptographic parts and found this vulnerability. He also developed actual code to mount the attack and was so kind to give me enough time to have a look at his paper and to gather a list of known type 20 keys owners. I am really sorry for this, Werner
    Open source isn't bug-free, but we thank the guy who finds the problem, take responsibility, and fix it.
    1. Re:Open v. Closed by Anonymous Coward · · Score: 5, Insightful

      Subtitle: Instead of suing him for being smart and violating the DMCA

    2. Re:Open v. Closed by Chris_Jefferson · · Score: 2, Insightful

      Good attempt at being clever, but seeing as GnuPG is open source, backward enginnering isn't nessasary. You can't get in trouble under the DCMA for finding holes in open source software I'm afraid..

      --
      Combination - fun iPhone puzzling
  5. Re:open source in crisis? by ajs318 · · Score: 4, Insightful

    Well, it depends on how you look at it. Sure ..... open source stuffs up occasionally. When we have a problem, everybody knows about it and it gets fixed. Whereas with closed source, the vendor can live in denial, pretending nothing has hapened, until the problem becomes serious enough to warrant attention.

    For some reason, things get invented in different places at roughly the same time. Vide the telephone {Alexander Graham Bell, SCO and Elisha Gray, USA}; the electric light bulb {Joseph Swan, ENG and Thomas Edison, USA} and the gramophone / phonograph {Emil Berliner, DBR and Thomas Edison, USA}. There are other examples, and I'm sure other countries have their own versions of who invented what.

    Also realise that, despite what the mass media are fond of telling you, good guys actually outnumber bad guys by one hell of a margin.

    Now, if both these principles - parallel invention and criminals in the minority - are true, then not only would the probability of a particular open source software vulnerability being discovered by a good guy be greater than the probability of it being discovered by a bad guy, but it is quite likely that if a bad guy were to discover a vulnerability, then a good guy also would discover it around the same time. Well, parallel invention has been proven throughout history, and good guys really do outnumber bad.

    Never judge someone on the basis of corrected mistakes. Most people don't get things right first time, and it's better to admit to a mistake and show how you fixed it than to pretend you never make mistakes.

    --
    Je fume. Tu fumes. Nous fûmes!
  6. Sign and encrypt keys by imaginaryNumber · · Score: 2, Insightful
    Werner says in his announcement:
    For historic reasons [3], GnuPG permits creating ElGamal keys which are usable for both encryption and signing. It is even possible to have one key (the primary one) used for both operations. This is not considered good cryptographic practice, but is permitted by the OpenPGP standard.

    I don't understand why it is 'not considered good cryptographic practice' to use the same key to sign and encrypt. Is Werner saying that this an ElGamal weakness or is it a general public-key encryption weakness? If it is not considered good cryptographic practice, then why is (was?) it in the OpenPGP standard?