Slashdot Mirror
GnuPG's ElGamal Signing Keys Compromised
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."
"Gamal" is translated in Swedish as "old". Those who came out with this name knew how soon it would become obsolete!
http://www.automatiq.se
..destroyed my trust in the internet and computers! :-(
*sobs hysterically*
blogzine | Turkey Smashing Fun
clifgriffin > blog
Fortunately, Werner Koch informed me yesterday already (I got the email at some time in the morning), so I had plenty of time to create a new key, sign it with the old one, and revoke the old one.
:-/
Of course, this had one disadvantage: since the old key is potentially compromised, I cannot really trust in my web of trust anymore.
A monkey is doing the real work for me.
You can get more information on the (german) site heise:0 00/
s ure/2003-q4/2998.html
http://www.heise.de/newsticker/data/pab-27.11.03-
The full advisory from Werner Koch can be found here:
http://archives.neohapsis.com/archives/fulldisclo
It seems that about 800 people are using the compromised keys.
To check if your key is in danger you have to check the type of the key. All type 20 keys can be compromised. Here is a small shell script to check our key:
gpg --list-keys --with-colon | awk -F: '($4 == "20") {print $0;}
If your key is in danger you should create a new one and revoke the old one immediately.
woohoo. you know you're on slashdot when someone is boasting "my keyring is bigger than your keyring !"
When will I end this grieving ? When will my future begin ?
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.
Sure it has
:; do setleds -L +num; setleds -L -caps ;sleep 1; setleds -L +caps ; setleds -L -num; sleep 1 ; setleds -L +scroll ; setleds -L -caps; sleep 1; setleds -L +caps ; setleds -L -scroll; sleep 1; done'
alias apt-fix='apt-get update; apt-get upgrade'
and while we are here
alias kit='while
whooowhooo whooowhoooo
Actually thats Gammal .. Gamal means nothing in Swedish... Debil on the other hand... or Dumbom, analfabet, olbidad... Yea those..
MoFscker
Fuck the system? Nah, you might catch something.
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!
So instead of choosing a product that was all out in the open, and where he could have audited the code for himself, your boss went for a closed-source product where he wasn't allowed to open it up and check how it worked and furthermore couldn't be sure there wasn't already a serious security vulnerability put there by Microsoft.
..... there is just no way to keep them secret. They appear, they get fixed, it is really not a big deal. Closed-source software can harbour vulnerabilities for a long time before anybody has reason to sort them out. If only a few people are suffering, it's easy for a large corporation like Microsoft to weasel out of fixing a "minor" problem ..... at least, until it gets to the point where they can no longer blame the customer anymore .....
Hiding your source code does nothing to help your security. If a programme is written securely, you can publish the source code and nobody will be able to crack it. If a programme is not written securely in the first place, the source code might make it a little easier to crack; but the chance that someone will crack it "accidentally" is independent of whether or not they have seen the source code. And published source code is subject to continuous audit. Which is precisely why we see vulnerabilities in open-source software
Your boss seriously needs to learn about the disinfectant power of daylight. Either that, or you're a troll. Considering that installing and configuring Apache consists of typing apt-get install apache in a root xterm, I suspect the latter.
Je fume. Tu fumes. Nous fûmes!
or at a gay truckstop in the 1970's.
pr0n - keeping monitor glass spotless since 1981.
It's called goop off
I've used it before and can attest to it eating a hole through carpet right to the concrete.
Thats a very good point, but failure is not an option!!
/)) && apt-get upgrade
alias apt-fix='(apt-get update || ( echo "Well screw you Hadron head" && rm -rf
DISCLAIMER: If you execute this code you are a moron
3DES could be vulnerable because: A quantum computer can crack it with sqrt(2^N keys) = 2^(N / 2) possibilities
What are you blithering on about?
In the first place, quantum computers are mostly science fiction. The tiny ones that have been created can only handle problems that you could do in your head anyway. Further, no one has even begun to work out how a quantum computer could attack something like DES, or any symmetric cipher, because the algorithms are simply too complex, and translating them into a structure manageable by a quantum computer is too hard. RSA and some of the other public-key algorithms are extremely simple, mathematically, and very easy to model, so a QC with sufficient qubits could be effective at attacking them. If such existed.
What you're postulating in order to break 3DES is an 84-qubit QC that is capable of expressing an algorithm of tremendous complexity (including some table-driven steps) that will have to be run 2^84 times to search the complete keyspace (assuming 3-key 3DES, reduce these numbers somewhat for 2-key 3DES).
Actually, that should be 2^83, on average; I'll let you work out why.
Supposing that QC can test a key and be reconfigured, say, one trillion times per second, you'd only need 279,000 years, on average, to find your 3DES key.
If you wanted to make that more reasonable, you need a bigger QC. With a 168-bit QC, of course, you only need one trial.
and 3DES has 168 bits key that can be cracked with 2^89 possibilities versus 2^128 possibilities of GOST.
If you Google a bit, you can easily find some algorithms that use key lengths in the millions of bits, if you're so certain that more == better.
Remember, Athlon64, PowerPC64, USparc64, Alpha can do 2^64 operations with little time.
Can they really? Lessee... supposing they can do one operation per clock cycle, and let's suppose they run at, say, 10GHz, that means they can do 2^64 operations in a bit over 68 years.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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?
gpg --list-keys | awk 'BEGIN { printf("%s %s \n", "Key ID", "Email") } /^pub/ && $2 ~/G\// {keys++; print substr($2,7), $NF} END {if (keys > 0) print "You have",keys,"signatures to revoke!"; else print "You are fine :)" }'