GPG is commonly used to sign source code tarballs such as the linux kernel. Those tarballs are mirrored across the world to hundreds of untrusted servers. With this flaw it's possible to modify signed source code (and introduce backdoors for instance). It's definitely not a theoretical problem.
No. Software is signed with detached signatures (that abcd.sig file that is distributed with the abcd.tar.gz). Detached signatures are not affected by this bug.
no flaw in encoding or decoding.. The problem is in display. It displays the unencoded preamble and postscript inline with the (properly) verified parts of the email. You then, essentially, have to guess which is which.
Not quite. Depending on how GnuPG is called, the output might be either the real signed data alone, the appended data alone, or a mix.
On second thought, that would be a seriously cool way to store video - stacks and stacks of frames. And if the power went out and you got bored, you could use them as flipbooks!
Don't laugh. That's exactly what used to happen in the early, early days of film in the US. For copyright protection, films had to be printed out frame by frame and deposited in the Library of Congress.
In more than one instance, the original film was lost but the paper prints survived - so people just rephotographed the paper prints to make a new copy of the film.
But it's not like 40 year old super 8 stock is known for clarity or color fastness anyway.
Depends on the stock. Old super 8 ektachrome fades after a few years. Kodachrome seems to last and look beautiful forever. Kodachrome is wonderful stuff.
To forestall the obvious question about GnuPG compatibility, GnuPG has had SHA-256, SHA-384, and SHA-512 since version 1.2.2 (2003-05-01) so it will interoperate nicely with the new PGP.
Incidentally, despite what the article implies, PGP has actually had SHA-256 support for a while now. It's not exposed in the GUI, but if you use GnuPG to generate a SHA-256 message, PGP can handle it.
In terms of what the SHA-1 "break" means, it is certainly time to start migrating to something stronger, but it is not time to panic and start revoking keys. Think of this as the MD5 situation in the late 1990s: a flaw was found, people migrated away, and when the serious MD5 crack was found last year, most people had already stopped using it.
The sky isn't falling. It's just a wake up call to start moving to something better.
Can someone explain what these Gnu/PG features that aren't in PGP are, and what they have to do with the key database?
Little stuff that can be annoying if you suddenly are incompatible. OpenPGP allows multiple photo IDs per key, and PGP only allows one. OpenPGP allows subkeys that can make signatures or encrypt, and PGP only allows subkeys that can encrypt. Stuff like that.
These things are part of keys, and if the keyserver is written to assume PGP-generated keys, it might not support them.
A central repository of public keys can bring problems, for example, if the central repository is located in USA and the FBI want to do a man-in-the-middle attack? How can you be assured that the public key from the guy you want to send a encrypted message is realy the correct public key?
That's not how PGP works. Just because a key comes from a particular keyserver doesn't mean that it is the right one. A keyserver just provides a convenient place to stick keys. The web of trust (which is local to your machine) tells you if a particular key is to be trusted or not.
This new keyserver doesn't change that. It just provides a convenient way to weed out clearly invalid keys so you don't have to bother with them. It's also opt-in: if you don't like that feature, use one of the many other keyservers out there located across the world.
What about spammers who want to harvest from this?
It's not a good harvesting target. You can only get *one* email address per search. If I were a spammer, I'd go somewhere that gives me more for less effort.
Still, even the old keyservers where you can get many addresses per search seem to be ignored by spammers. Even they are not rich enough of a target.
I vaguely remember that the short key ID used a flimsy hash, but to avoid that you only had to verify the key length.
If you and I are remembering the same thing, that was under a different attack. IIRC, that wasn't even an attack on the hash, but just on the way that fingerprints were generated. But it's been a long time, so I may be misremembering.
Here's the deal: old PGP 2.6 keys used MD5 as the hash algorithm to make a fingerprint. Due to a flaw in the design, the key bits, but not the length of the key was fed into the hash. Thus, it would be possible to manufacture a key with a fingerprint that matched someone elses. The trick was to 'slide' bits from one value to the next.
i.e. is it:
"1111111122222222" where the two values are "11111111" and "22222222"
or is it:
"1111111122222222" where the two values are "111111" and "1122222222"
If you give the key length, it foils the attack since doing this trick ends up with a different sized key than the original.
As you say, it is not an attack on the hash. It was a flaw in the old PGP 2.6 protocol. It hasn't really worked that way since 1997 or so, though some people still use their 2.6 keys.
I use GPG; downloaded a GPG for Windows and put it right on the key so that I can use it in any Windows machine as well.
A lot of people do this (keep a GPG key on a removable USB memory key), but it isn't always a good idea. Remember that the USB memory keys provide a filesystem to the host computer, so it is possible for something on that box to simply copy your key. Make sure you trust the box before you plug in your memory key.
If the message is some text (as opposed to binary information), then a sufficiently powerful computer (whatever that means) can try out all possible combinations of bits in all possible positions given the length of the message to try to extract the information. Combine this with a dictionary and grammar rules, and eventually the message pops out.
It doesn't work that way, exactly.
A true one-time pad is unconditionally secure because there is no way to determine when your proposed powerful computer has cracked the message.
For example, given the string "jsdlf341kj,snvcq", it could translate to "What's new?" or "Attack at dawn!" depending on what the key is. Without the key, you might translate it into a parseable message, but you have no way of knowing if that is the real message.
Based on the false attacks on innocent folks, I'd check my proposed new address against the database so I wouldn't _be_ targetted.
Not to equate real world attacks and the net, but this is something that is starting to happen with IP allocations as well. If the "previous tenant" of an IP block was a spammer, nobody wants the block because they'd have to spend months trying to get themselves out of all of the blocklists. The "set it and forget it" ad hoc lists would never unblock them.
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?
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.
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.
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:
If you make a signature, your private key can be compromised.
If you make a new key, it is compromised from the start since the new key contains signatures from itself (the user ID and subkey binding signatures).
Elgamal sign+encrypt keys have been deprecated in GnuPG for a long time now. Much effort was put into discouraging people from using them. In hindsight, they should have been dropped completely. Hindsight is easy though.
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.
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.
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.
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. RSA is not limited in its hash, so they can use whatever hash they like. DSA is also limited to a 1024-bit key, while RSA is not.
It breaks down like this:
RSA: much faster to verify signatures, can be any size, can use any hash, signatures are large. DSA: much faster to make signatures, maximum of 1024 bits in size, can only use 160-bit hashes, signatures are small.
They're both fine choices. It depends on what your goals are.
There are historical reasons. Basically, when GnuPG was first written there were still questions about the patent status of DSA, so using Elgamal signatures was allowed. This is not against the OpenPGP standard, by the way, which does allow Elgamal signatures.
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.
No, that was correct - there are only 848 of these keys on the keyservers (so a reasonable approximation of "worldwide"). This is a VERY infrequently used key type: around 0.04% of keys. It was only supported in GnuPG for backwards compatibility reasons, and each release put more and more barriers in front of its use.
On the other side of the coin, if everything is protected by PGP (email too), then the workers can't be snooped on, and who knows what those evil little ants could be doing!
PGP comes with corporate access features (the "ADK") so that the boss can always read employee messages. Needless to say, it's a controversial feature, but companies don't like the idea of an employee encrypting all their work and then, say, walking in front of a bus.
Slashdot Mirror
This applies to a very specific case where a message is constructed by hand with multiple data packets and a single signature packet, so:
I say "might" as in all of these cases it depends on how GnuPG is called.
No. Software is signed with detached signatures (that abcd.sig file that is distributed with the abcd.tar.gz). Detached signatures are not affected by this bug.
Not quite. Depending on how GnuPG is called, the output might be either the real signed data alone, the appended data alone, or a mix.
On second thought, that would be a seriously cool way to store video - stacks and stacks of frames. And if the power went out and you got bored, you could use them as flipbooks!
Don't laugh. That's exactly what used to happen in the early, early days of film in the US. For copyright protection, films had to be printed out frame by frame and deposited in the Library of Congress.
In more than one instance, the original film was lost but the paper prints survived - so people just rephotographed the paper prints to make a new copy of the film.
http://memory.loc.gov/ammem/edhtml/edppr.html
But it's not like 40 year old super 8 stock is known for clarity or color fastness anyway.
Depends on the stock. Old super 8 ektachrome fades after a few years. Kodachrome seems to last and look beautiful forever. Kodachrome is wonderful stuff.
To forestall the obvious question about GnuPG compatibility, GnuPG has had SHA-256, SHA-384, and SHA-512 since version 1.2.2 (2003-05-01) so it will interoperate nicely with the new PGP.
Incidentally, despite what the article implies, PGP has actually had SHA-256 support for a while now. It's not exposed in the GUI, but if you use GnuPG to generate a SHA-256 message, PGP can handle it.
In terms of what the SHA-1 "break" means, it is certainly time to start migrating to something stronger, but it is not time to panic and start revoking keys. Think of this as the MD5 situation in the late 1990s: a flaw was found, people migrated away, and when the serious MD5 crack was found last year, most people had already stopped using it.
The sky isn't falling. It's just a wake up call to start moving to something better.
Can someone explain what these Gnu/PG features that aren't in PGP are, and what they have to do with the key database?
Little stuff that can be annoying if you suddenly are incompatible. OpenPGP allows multiple photo IDs per key, and PGP only allows one. OpenPGP allows subkeys that can make signatures or encrypt, and PGP only allows subkeys that can encrypt. Stuff like that.
These things are part of keys, and if the keyserver is written to assume PGP-generated keys, it might not support them.
A central repository of public keys can bring problems, for example, if the central repository is located in USA and the FBI want to do a man-in-the-middle attack? How can you be assured that the public key from the guy you want to send a encrypted message is realy the correct public key?
That's not how PGP works. Just because a key comes from a particular keyserver doesn't mean that it is the right one. A keyserver just provides a convenient place to stick keys. The web of trust (which is local to your machine) tells you if a particular key is to be trusted or not.
This new keyserver doesn't change that. It just provides a convenient way to weed out clearly invalid keys so you don't have to bother with them. It's also opt-in: if you don't like that feature, use one of the many other keyservers out there located across the world.
What about spammers who want to harvest from this?
It's not a good harvesting target. You can only get *one* email address per search. If I were a spammer, I'd go somewhere that gives me more for less effort.
Still, even the old keyservers where you can get many addresses per search seem to be ignored by spammers. Even they are not rich enough of a target.
If you and I are remembering the same thing, that was under a different attack. IIRC, that wasn't even an attack on the hash, but just on the way that fingerprints were generated. But it's been a long time, so I may be misremembering.
Here's the deal: old PGP 2.6 keys used MD5 as the hash algorithm to make a fingerprint. Due to a flaw in the design, the key bits, but not the length of the key was fed into the hash. Thus, it would be possible to manufacture a key with a fingerprint that matched someone elses. The trick was to 'slide' bits from one value to the next.
i.e. is it:
"1111111122222222" where the two values are "11111111" and "22222222"
or is it:
"1111111122222222" where the two values are "111111" and "1122222222"
If you give the key length, it foils the attack since doing this trick ends up with a different sized key than the original.
As you say, it is not an attack on the hash. It was a flaw in the old PGP 2.6 protocol. It hasn't really worked that way since 1997 or so, though some people still use their 2.6 keys.
You know that GPG keys are identified and signed by their MD5 hashes?
They're not. The old PGP 2.6 keys are, but GnuPG generates OpenPGP keys that use SHA-1.
GnuPG will use an already generated PGP 2.6 key, but will not make more of them.
A lot of people do this (keep a GPG key on a removable USB memory key), but it isn't always a good idea. Remember that the USB memory keys provide a filesystem to the host computer, so it is possible for something on that box to simply copy your key. Make sure you trust the box before you plug in your memory key.
A better way: the OpenPGP smartcard
The MD4 collision has been verified.
The MD5 collision has some problems, but the researchers are trying to re-run their code before tonight's presentation.
It doesn't work that way, exactly.
A true one-time pad is unconditionally secure because there is no way to determine when your proposed powerful computer has cracked the message.
For example, given the string "jsdlf341kj,snvcq", it could translate to "What's new?" or "Attack at dawn!" depending on what the key is. Without the key, you might translate it into a parseable message, but you have no way of knowing if that is the real message.
It is not at all encumbered, and in fact GnuPG uses it. No patent, no royalty. No muss, no fuss.
Not to equate real world attacks and the net, but this is something that is starting to happen with IP allocations as well. If the "previous tenant" of an IP block was a spammer, nobody wants the block because they'd have to spend months trying to get themselves out of all of the blocklists. The "set it and forget it" ad hoc lists would never unblock them.
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.
Thus, the signing bug caused two problems:
Elgamal sign+encrypt keys have been deprecated in GnuPG for a long time now. Much effort was put into discouraging people from using them. In hindsight, they should have been dropped completely. Hindsight is easy though.
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.
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. RSA is not limited in its hash, so they can use whatever hash they like. DSA is also limited to a 1024-bit key, while RSA is not.
It breaks down like this:
RSA: much faster to verify signatures, can be any size, can use any hash, signatures are large.
DSA: much faster to make signatures, maximum of 1024 bits in size, can only use 160-bit hashes, signatures are small.
They're both fine choices. It depends on what your goals are.
There are historical reasons. Basically, when GnuPG was first written there were still questions about the patent status of DSA, so using Elgamal signatures was allowed. This is not against the OpenPGP standard, by the way, which does allow Elgamal signatures.
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.
No, that was correct - there are only 848 of these keys on the keyservers (so a reasonable approximation of "worldwide"). This is a VERY infrequently used key type: around 0.04% of keys. It was only supported in GnuPG for backwards compatibility reasons, and each release put more and more barriers in front of its use.
Palm seems to be stepping up the pace of their model releases. The T3 is already rumored.
Landscape-able screen, and you can actually use the area underneath the slider. Pretty nifty.
For me, the T2 is too little of a improvement over the T to justify buying it. Plus, a forced conversion to Grafitti 2 embodies the concept of "suck".
Of course, by the time the T3 is out, the T4 will be rumored, complete with photos...
"Sir, please put away your phone while you are on this flight!"
"But, it's my organizer..."
"Sorry, it's a phone. Put it away."
GnuPG ignores ADK packets, incidentally.