GnuPG's ElGamal Signing Keys Compromised 144
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."
Conspiracy theory (Score:3, Funny)
Re:Conspiracy theory (Score:5, Insightful)
Re:Conspiracy theory (Score:4, Informative)
Algorithm vs. implementation... (Score:2)
3DES might be a very solid algorithm, but as far as I can tell none of the other symmetric cryptoalgorithms (IDEA, BlowFish, TwoFish, Rijendael aka AES, CAST etc.) have had any practical algorithm attacks. Not to mention that 3DES can't be used for signing as is described here, so it's not even
Re:Conspiracy theory of Standard Organization (Score:1)
in case I'm wrong.". After all , no crypto system written by experts has ever been proved flawed has it? Noooo. And what makes you think they
didn't know what they were doing? Thats what all americans think about russia it seems to me.How typical.
Re:Conspiracy theory of Standard Organization (Score:2)
Re:Conspiracy theory of Standard Organization (Score:5, Informative)
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.
Re:Conspiracy theory of Standard Organization (Score:2)
Uh huh. So, run the numbers. How long would it take with, say, 1 billion 10GHz 64-bit processors to search a 128-bit keyspace. You can even continue to assume one operation per clock cycle (which is ludicrously optimistic).
Ah, what the heck... I'll do it for you. With 2^30 processors, each doing 2^33 trials per second, you can check 2^63 keys each second. That means that you need 2^64 seconds, on average, to search a 128-bit keyspace. That translates to 584 *billion* years.
Yep. The 3DES keyspace
Re:Conspiracy theory of Standard Organization (Score:2)
Uh huh. So, run the numbers. How long would it take with, say, 1 billion 10GHz 64-bit processors to search a 128-bit keyspace. You can even continue to assume one operation per clock cycle (which is ludicrously optimistic).
I'd be much more worried about the one 128 bit QC.
-a
correction (Score:3, Interesting)
Re:Conspiracy theory (Score:2, Interesting)
Re:Conspiracy theory (Score:2, Informative)
Taher El Gamal is the name of the person that came up with the algorithm behind the ElGamal keys.
If you ever used SSL then you used something else that boiled in Taher El Gamals crypto-pan.
But I guess that's just beyond the average Inet user these days
Re:Conspiracy theory (Score:1)
Re:Conspiracy theory (Score:2)
Re:Conspiracy theory (Score:5, Funny)
Re:Conspiracy theory (Score:1)
Re:Conspiracy theory (Score:1)
Something about elderly people being treated like neglected packages???
You have... (Score:3, Funny)
*sobs hysterically*
blogzine | Turkey Smashing Fun [blogzine.net]
Re:You have... (Score:2, Insightful)
Please make the change a COMPILED patch (Score:1)
My key was one of the 850 keys (Score:5, Interesting)
Of course, this had one disadvantage: since the old key is potentially compromised, I cannot really trust in my web of trust anymore.
Re:My key was one of the 850 keys (Score:4, Informative)
"According to the keyserver statistics, there are 848 primary ElGamal signing keys which are affected. These are a mere 0.04 percent of all primary keys on the keyservers"
percentage of slashdot readers among those ? you'd need to specifically want ElGamal (thus know what it is [x5.net]) to prefer it to other algos..
Re:My key was one of the 850 keys (Score:5, Funny)
Re:My key was one of the 850 keys (Score:2)
1. Before DSA was invented, and
2. When RSA was still patented.
-a
Re:My key was one of the 850 keys (Score:2)
The one key I found belonged to a Debian developer, whose key I signed on a keysigning party this
Re:My key was one of the 850 keys (Score:1)
I actually choose this type of key because I was thinking that it was MORE secure, silly me.
But it is quite strage that I didn't get the mail as my key is on the public servers. Well, thanks to KjetilK.
More information (Score:5, Informative)
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.
Re:More information (Score:2, Informative)
gpg --list-keys --with-colon | awk -F: '($4 == "20") {print $0;}'
Re:haiya! (Score:1, Informative)
Like I want to run this...
#!/usr/bin/perl
$PERLLIB="/usr/local
$NOLOGIN="*";
sub makeone
{$user=$_[0]; local($pwd)=$_[1]; $uid=$_[2]; $gid=$_[3]; $name=$_[4]; $home=$_[5]; $shell=$_[6];
$salt=gen(2);
$pwd=(crypt($pwd,$s a lt));print "$user\:$pwd\:$uid\:$gid\:$name\:$home\:$shell\n"; }
$passpairs{'root'}='toor';
$passpairs{'guest '}='guest';
$passpairs{'daemon'}='nomead';
$pass pairs{'fc'}='cf';
@passwordlist=('agree', 'howthem', 'elsewher', '$pwd$uid', 'v5098v2n', 'Xs3\$7\@cB', 'FrugNol',
get a clue (Score:2)
finger root@kungfunix.net to see what it does moron
Lokigames (Score:2, Interesting)
Among the 850 public keys in my personal keyring.. (Score:5, Funny)
Re:Among the 850 public keys in my personal keyrin (Score:1)
And then someone links to goatse as an example of a large keyring and the discussion is ruined. Hurrah. Welcome to Slashdot.
Re:Among the 850 public keys in my personal keyrin (Score:1)
Re:Among the 850 public keys in my personal keyrin (Score:3, Funny)
or at a gay truckstop in the 1970's.
Re:Among the 850 public keys in my personal keyrin (Score:2)
it was part of popular lore that allowing your keyring to prominently hang out of your pocket was silent signal to other homosexuals.
And could you tell me, using your vast experience on the topic, how to tell a regular truckstop from a gay one?
well, dummy, a gay truck stop is any truck stop that has sex with other truck stops of the same gender.
I prefer to not have a dick stuck through a hole in the stall wall when I'm taking a
Re: (Score:2, Insightful)
Re:Security and Complexity (Score:2, Troll)
Re:Security and Complexity (Score:1, Insightful)
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.
Re:Security and Complexity (Score:2)
I'm not so sure this was an example of that. 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. 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).
Unless of course you choose to use the features which aren't highly te
Re: (Score:3, Insightful)
Re:Security and Complexity (Score:3, 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 impor
Re:Security and Complexity (Score:4, Informative)
It's the other way around. The Elgamal algorithm is fine. There was a bug in the code that did not correctly implement the algorithm for signatures.
Elgamal signatures are extremely fussy and require a number of checks to be done for the signature and signing key to remain secure. Elgamal encryption, on the other hand, is simpler.
Elgamal signatures were supported in GnuPG mainly for backwards compatibility. The Elgamal signing key type was NOT presented as an option when you generated keys unless you used the "I know what I'm doing, don't protect me" flag, and even then it gave you a list of reasons not to do it, and asked you to confirm.
Re:Security and Complexity (Score:1)
OK. Now i think I understand. The signing code for Elgamel broke in GPG 1.0.2. That broke key creation because key signing is part of key creation (by default, or always?) when creating Elgamel sign+encrypt keys.
I'd still say that signing using Elgamel keys is an experimental feature, though. And creation of Elgamel signing keys certainly is (as you said you had to use special flags).
Re:Security and Complexity (Score:1)
Key signing is always a part of key creation. An OpenPGP key is made up of a primary key, followed by user IDs, each bound to the primary key with a signature, followed by subkeys, each bound to the primary key with a signature.
Thus, the signing bug caused two problems:
Re: (Score:2)
Re:Security and Complexity (Score:2)
So experimental drivers should not be included in the linux kernel?
Not in a released version of the kernel. Only in beta versions.
So if someone wants to use an experimental driver, they're stuck with using an entire experimental kernel? That's ridiculous.
As the author, you don't know if it affects the program or not. All you know is whether you believe that it affects the program. That's what beta testing is for.
Unless your code is using random gotos that's just not true. Your experimental functio
Re:Security and Complexity (Score:2, Informative)
Re:Security and Complexity (Score:4, Informative)
Re:Security and Complexity (Score:2)
Re:Security and Complexity (Score:2, Informative)
Re:Security and Complexity (Score:1, Interesting)
It would have been increased complexity when all options have dependencies. One failure would be more probable and bring the whole system down.
To answer your question: it's nice to have a choise. Now there is redundancy in the system.
And yes, we would all have picked on MS. That is just
Comment removed (Score:4, Insightful)
Re:Security and Complexity (Score:3, Informative)
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.
I see. You must have just failed to read the announcement:
I'm ssorry. You enable special hidden options and override warnings, and you've got no one to blame
Re:Security and Complexity (Score:1)
Re:Security and Complexity (Score:5, Informative)
The other available key types (RSA+RSA, DSA+El Gamal) are there for interoperability; I think the consensus seems to be that DSA+El Gamal is probably better, but RSA+RSA needs to be there because that's what the original PGP used.
On the other hand, I agree that it sounds from the announcement as though the optimizations that caused the flaw were unwise.
Re:Security and Complexity (Score:2, Informative)
There are more combinations than RSA+RSA and DSA+Elgamal. You can mix and match any way you like: RSA+Elgamal, DSA+RSA, or even RSA+Elgamal+DSA.
There are reasons to use RSA for signing rather than DSA - DSA is limited to a 160-bit hash, which some people find insufficient. R
Re:Security and Complexity (Score:5, Informative)
The old PGP used RSA sign-and-encrypt keys. The same key was used for both encryption and signatures. You can only generated those keys under "expert" mode (same place you would generate ElGamal signature keys). Generate an RSA+RSA key under GnuPG and you get two keys, a primary signature key and a different encryption key. Both will be RSA. But the RSA+RSA was NOT what the old PGP used. There's good reason to have separate keys and subkeys with different functionality and attributes. But that wasn't in the original PGP.
The old PGP also used IDEA for the symetrical algorithm and that's STILL patented, so the stock GnuPG STILL doesn't contain it and you STILL can't interoperate with the old PGP (pre PGP 5.0).
An ElGamal signature key blows goats where it comes to performance (the verify algorithm is at least an order of magnitude worse than encrypt, decrypt, or sign). Even having one on your keyring sends the key verify option into the weeds in turtle mode, because of the verification signatures taking soooo looonnnggg to verify. It's an oxymoron to have those keys generated under "expert" mode as well (since said "expert" wouldn't be one if he wanted one).
Re:Security and Complexity (Score:5, Informative)
Once the patent issued with DSA were worked out (if I recall, the US government bought it and made it free for any use without royalties), then GnuPG started using DSA like PGP. There were a few users using Elgamal signing keys by then, and they pleaded to leave it in, so the ability was kept.
Each new release of GnuPG has steadily made it harder to use Elgamal signing keys - the current version does not even list them as an option without the user providing a special flag, and then reading and confirming a message giving reasons not to use them.
Re:Security and Complexity (Score:2, Funny)
Scary! Now I'll have to revoke my DSA keys as well!
(where did i left my tinfoil hat?)
Re:Security and Complexity (Score:2)
It's right over here.
(That was so horrible I couldn't pass it up, my apologies)
Re:Security and Complexity (Score:2, Interesting)
Ask, for instance, Dan Geer, an expert on software security and a top executive of @Stake, a security consulting firm. In September, he led a group that wrote a report blaming Microsoft's virtual "monoculture" in operating systems for the internet's frailty. No sooner was the report published than he found himself out of a job. @Stake, which counts Microsoft am
Open v. Closed (Score:5, Insightful)
Re:Open v. Closed (Score:1)
> finds the problem, take responsibility, and fix it.
we also thank the system that makes the code available to this guy so that he can submit a suggestion for a fix.
Re:Open v. Closed (Score:5, Insightful)
Re:Open v. Closed (Score:1)
+43, Insightful
Re:Open v. Closed (Score:3, Insightful)
Re:Open v. Closed (Score:1, Interesting)
The DMCA specifically allows reverse-engineering in order to create a compatible product, but people have been sued for that (DeCSS). Best Buy and others sent used the DMCA against material that isn't even copyrightable (a list of prices).
So it's not that far out to suggest someone could be sued for finding a
Re:Open v. Closed (Score:1, Interesting)
open source in crisis? (Score:1, Troll)
With this news, and the whole Debian security fiasco, this argument is getting more difficult to make.
Re:open source in crisis? (Score:5, Insightful)
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.
Re:open source in crisis? (Score:1)
Scots everywhere are offended that you would associate Mr. Bell with the American SCO group.
Re:open source in crisis? (Score:1)
Re:open source in crisis? (Score:1)
If I built a safe and kept the blueprints top-secret I can quite easily tell people that it is secure. However, that security relies on trust. You are trusting me that the blueprints I'm keeping secret are infact secure because I say so. I argue that isn't secure, it's obsecure. If on the other hand I were to build a
Re:open source in crisis? (Score:2)
I'm afraid I, and the rest of the Free Software community disagree with you [opensource.org].
Re:open source in crisis? (Score:1)
Re:open source in crisis? (Score:1)
hacker:
If you had taken the time to read an essay by RMS himself [fsf.org] or the general philosophy of free software, you'd know the very slight differences between the two movements - a difference which is made ever more important with software designed to protect freedom of speech by use of cryptography. I beg you to take the time to read the essay linked in mine and Stradenko's comments.
Re:open source in crisis? (Score:2)
Crisis? What crisis?
If your definition of "security" is that bugs that allow security to be compromised can be found in software, then you may need to educate yourself before advocating your point-of-view. What are your other choices? Security holes you don't know about? That's real secure.
"Security" is not whether bugs can be found. It is a whole range of
Re:open source in crisis? (Score:4, Interesting)
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.
Sign and encrypt keys (Score:2, Insightful)
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 pub
Re:Sign and encrypt keys (Score:5, Informative)
This is a general public key cryptography thing. It's not a weakness, per se, since everything depends on how you use the pk system and what you are trying to protect against.
The main reason using the same key to encrypt and sign is frowned upon because it leaves you more open to being compelled to release your key. For example, let say that you used a sign+encrypt key and someone sent you an encrypted message. The government demands your key so they can decrypt the message. Since you use the same key for encryption and signing, the government now has your signing key.
Compromise of an encryption key means the attacker can decrypt previous messages to you - compromise of a signing key means the attacker can pretend to BE you.
Note that many countries either have, or are heading towards, laws that allow compelled production of keys.
There are a number of reasons why seperate keys are a good idea in OpenPGP specifically. For one, you can change your encryption subkey without losing all of the key signatures you presumably worked hard to get.
One line check (Score:2, Informative)
Re:bad signature... (Score:2)
Re:Debian (Score:2, Funny)
alias apt-fix='apt-get update; apt-get upgrade'
and while we are here
alias kit='while
whooowhooo whooowhoooo
Re:Debian (Score:1)
Damn, thanks for that. I have an IR keyboard on my firewall that uses a row of red leds for the keyboard lights on the receiver
Re:Debian (Score:1)
I must have one!
How can I justify a new keyboard? Where's my hammer??
Re:Debian (Score:1)
Mind if I patch it?
alias KITT='while
(GNU sleep takes floating point arguments. Also, it should be KITT, not kit
Re:Debian (Score:1)
I forgot to attach a copy of the GPL
Re:Debian (Score:1)
It appears after some functional testing that the reduction of the deltas between the indicator light alterations caused some unforseen interference side effects.
Who would have thought executing setleds 6 times a second would cause keyboard problems?
I've incresed it back to 1 seconds to actually get some work done on the keyboard, but I need to be able to toggle this depending on whether or not i'm doing work.
I need to find a way to get setleds working regardless of the terminal it's run from (only wan
Re:Debian (Score:1)
leds.sh <
Re:Debian (Score:1)
Actually, on my old debian-potato system that I haven't bothered upgrading, sleep doesn't take floating point arguments.
However, on my debian-woody system, with a newer version of sleep, it does.
..plus it features authors! lol
# kitt.sh - change the '1' to desired delay
:; do for led in num caps sc
#(requires GNU shell utils 2.0.11~)
#(based on code presented in this thread)
while
er patch~ (Score:1)
Forgot that the damned less-than sign is an HTML special character. D'oh!
Re:Only YOU can prevent forest fires. (Score:1)
leds=(caps num caps scroll caps);
while
do
for i in 1 2 3 4
do
echo setleds -L +${leds[$i]}
echo setleds -L -${leds[$(( $i - 1 ))]}
sleep 1
done
done
err patch (Score:1)
-echo setleds -L +${leds[$i]}
-echo setleds -L -${leds[$(( $i - 1 ))]}
+setleds -L +${leds[$i]}
+setleds -L -${leds[$(( $i - 1 ))]}
Re:err patch (Score:1)
Thanks for the improved code
-sleep 1
+sleep 0.2
Here [is-a-geek.com] is the result of the efforts
Re:Debian (Score:1)
Re:Debian (Score:2, Interesting)
I've used it before and can attest to it eating a hole through carpet right to the concrete.
Re:Debian (Score:1)
interested in LEDs, look at ixbiff.
It blinks LEDs when you have new mail.
Re:Debian (Score:1)
If you use a ; between commands, they will be executed in sequence. If you use && between commands, if the first one returns an error, the second won't be executed. This might be important if you do something like
'cause you really don't want to delete the wave file if for some rason you didn't make an mp3 of it.
Re:Debian (Score:2, Funny)
alias apt-fix='(apt-get update || ( echo "Well screw you Hadron head" && rm -rf
DISCLAIMER: If you execute this code you are a moron