PGP Vulnerability Discovered 247
From Bruce:
PGP Vulnerability
A very serious PGP vulnerability was just discovered. Using this vulnerability, an attacker can create a modified version of someone's public key that will force a sender to encrypt messages to that person AND to the attacker.
Let me explain.
When Network Associates joined the Key Recovery Alliance, they modified PGP to allow for third-party key recovery. They did this by supporting something called an Additional Decryption Key (ADK). Normally, when a PGP user creates a PGP certificate, it contains a single public key (as well as identifying information as to who the key belongs to). PGP version 5 and 6 allow the user to add additional ADKs to the certificate. When a sender encrypts a message to that user, PGP will automatically encrypt the message in both the user's public key and the ADK. The idea is that the ADK belongs to the secret police, or the user's employer, or some organization, and that organization can intercept the encrypted message and read it.
A stupid idea, but that's the sort of thing that Key Escrow demands.
The flaw is that some version of PGP don't require the ADKs to be in the signed portion of the PGP certificate. What this means is that an organization can take a PGP certificate, append his ADK, and spread it out to the world. This tampered version of the certificate will remain unnoticed by anyone who doesn't manually examine the bytes, and anyone using that tampered version will automatically and invisibly encrypt all messages to the organization as well as the certificate owner.
Unfortunately, the problem won't go away until all vulnerable versions of PGP are eradicated: the sender who is responsible for encrypting to the ADKs, not the recipient.
Way back in 1998 a bunch of us cryptographers predicted that adding Key Escrow would make system design harder, and would result in even more security problems. This is an example of that prediction coming true.
Re:Am i missing the point of PGP (Score:1)
We use encryption to ensure that our IP is secure, not so that your private email is secure. We own the IP, therefore we have every right to be able to decrypt any message that our employee sends using company equipment, in this case, computer, bandwidth, encryption key.
I agree with that.. thats why I have a personal key, generated at home, that I use for 'other' communication... granted, its probably shot to hell now, BUT...
Re:Open Source at it's best--not (Score:2)
I'd much rather have a smaller number of people working much more intensively on something, ala the ongoing OpenBSD security audit, to catch problems before anyone is burned. "Sure, the bridge fell down, but look at how quickly we re-engineered and rebuilt it!" is cold comfort to those who were on the bridge when it collapsed.
What's vulnerable and what's not (Score:2)
There is a lot of confusion here about what versions of PGP/GPG are vulnerable and which are not. Here is what I believe to be an accurate summary.
The attack works when A modifies B's key, which must be in version 4 format, and passes it on to C. If C's software honors the extra ADK which was added on the sly, then all messages that C sends to B can be read by A.
So, there are three things required to make the security fail:
(1) A must be able to modify the key sent from B to C somehow.
(2) B must be using key format version 4
(3) C must be using sofware that honors ADKs.
Obviously (1) is not software-related. If you give your key directly to your correspondent, you're ok. (Though if you are really paranoid, remember that the adversary could modify it as it sits on B's hard drive, even after you've exchanged a few safe messages.)
The only software that avoids condition (2) is PGP 2.6.x, which sticks to key format version 3. PGP 5+ and GPG use version 4 and are both vulnerable to key tinkering! So all those saying GPG is not affected are only half-right. (Hopefully will be fixed soon.)
Condition (3) is met by PGP versions 5 and 6 on Windows. If C sends with PGP 2.6.x or GPG, the exploit will not happen.
So, the only way B can feel safe (being the receiver) is to use PGP 2.6.x. C can feel safe sending with that or with GPG.
-Mandos
This can probably be detected by email recipient (Score:2)
Of course this may give false alarms with emails which where intentionally encrypted to more than one recipient, but the software should probably be configurable to warn about this.
So you may get aware of the problem and can contact the sender of the email to see if he is using a tampered key / pgp version.
Re:gpg (Score:2)
Bill - aka taniwha
--
Re:DeCSS sucks and so do you! (Score:2)
...phil
Re:Not new or secret (Score:2)
Yeah, right. Try telling that to Kevin Mitnick.
...phil
Re:Why key escrow? (Score:2)
Ignoring your basically clueless estimate of the computing power available to the government, did your calculation take into account the amount of effort it takes to break the session key? "Session key? What's that?" you ask. Gee, didn't bother to read the documentation, did you? Why don't you go do your math again, only this time use the session key size (128 bits, last time I heard), and see what results you get. Also, you might check a message somewhere above this one, wherein somebody suggests that the session key is pretty poor quality, thus making the keyspace that much smaller.
...phil
Re:gpg (Score:2)
You can use methods such as egd.pl (as described and linked for download at http://www.lothar.com/tech/crypto/ [lothar.com]) to gather entropy for random seeds and a third party /dev/random device driver such as the one at http://www.cosy.sbg.ac.at/~andi/ [sbg.ac.at] though. Also, OpenSSH has its own internal method of gathering entropy - such as running netstat and viewing the ps table.
You're not *that* dependent on the OS for randomness, it just takes a bit more work if you start with a hobbled one.
That's why I'm part of the GNU Generation. . . (Score:2)
How to Find the ADK (Score:2)
The only way to be *sure* that you or your correspondant aren't encrypting your data in such a way that a 3rd party can read it, is to check it yourself.
This utility might be of help: pgpdump-0.02.tar.gz [195.115.63.44]
It will dump the format of your PGP encrypted data, telling you about all the keys that the data was encrypted for.
You can of course use this utility on both your own encrypted data and encrypted messages that you get from others.
--
Why pay for drugs when you can get Linux for free ?
Re:Explanation of the problem (Score:2)
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Can't you just look at the header information, to see what version it was encrypted with?
It's a bit late by then - if the key was tampered with, and the version of PGP used to encrypt the data was vulnerable, then the data will be readable by whoever tampered with the key.
Of course, finding out that the key was tampered with (which you can do by checking for additional recipients in the encrypted message) is useful in itself.
Re:I was having a chat... (Score:2)
In the MPAA vs 2600 case, it's the same thing. 2600 didn't do anything, just reported it, like this kid. Yet they are successfully sued. Not only that, but this security hole that's being pointed out in PGP was clearly found (or at least researched) by the decompiling of the PGP source and reverse-engineering it's storage specs, right?
Even if some of those specs are public, certainly the fact that PGP works this way is not published anywhere (previously) and someone had to "hack" this system to get the info. Clearly illegal behaviour under the DCMA under any circumstance.
The PGP source code is available - no reverse-engineering was done. Ralf, the author of the original paper, explicitly says that his tests were done without looking at the source to PGP: he was just testing the behaviour experimentally. And anyway, PGP is not a system for controlling access to copyrighted works, so has little to do with the DMCA.
Re:So just use "authorized" keys. (Score:2)
The quickest "patch" would be for the key servers to discard any parts of the public key block that are outside of the self-signed portion. This would prevent people from using the key servers to distribute poisoned keys.
Of course, that requires trusting your key server, which you shouldn't have to do (that's what key signing is for). At least it would make exploitation harder. As it stands a script kiddie could probably exploit the problem.
Re:Look at the name (Score:2)
You should use RSA because it is a well-studied algorithm. When used properly it is secure.
Apparently you're not a crypto-scientist, if you've never heard of a "meet in the middle" attack (note: this is different from a "man in the middle" attack). Meet-in-the-middle is why people use 3DES instead of 2DES; 2DES is not really stronger than 57 bits even though the key size is 112 bits. 3DES is still subject to meet-in-the-middle; even though the key size is 168 bits it is "only" 112 bits strong (which is plenty strong).
With public-key algorithm like RSA it's even worse. Each key can be broken totally independantly no matter how many keys you use. "3RSA" would be a waste of time.
Just use a long RSA key. 1024 bits is enough, but computers are fast enough that you may as well use longer (2048 bits is plenty). The current state-of-the-art in factoring can break just over 512 bits. 1024 is a long way off unless you expect some massive breakthrough in quantum computers (the best quantum computers today are less useful than a pocket calculator).
NAI's key escrow function is a "small and subtle" change, and look what it's done. And NAI even has real "crypto-scientists".
Don't fuck around with crypto if you're not an expert. The experts get it wrong often enough; we don't need you screwing things up even more. We already have too many amateurs screwing things up.
This tells me you don't even understand what public key crypto is about.
I can't emphasize enough: Do not go "improving" crypto unless you already have a bunch of cryptanalytic experience.
Re:Sue Him ! (Score:2)
He has illegally circumvented a carefully designed protection mechanism !
Re:Hold on (Score:2)
Re:So just use "authorized" keys. (Score:2)
The paper suggests using gpg --list-packets on the keyfile as an analysis tool. It appears that you should be looking for an "additional recipient request" subpacket, which (when attacked) would presumably not be hashed as in the example shown.
Win32 (Score:2)
I don't think that's it at all. The previous poster was probably thinking of this-
From readme.w32 in the GPG W32 ALPHA release:
This is an alpha release of GnuPG for MS-Windows and WNT.
The random number generator should now work but has not undergone
a thorough testing, so we won't say anything about the quality of
the generated key and suggest that you don't use this version with
your production secret keys!
The new version of GPG (1.0.2) doesn't have this warning though, so I'd imagine they've validated the RNG.
-K
8=^`=`^=D
Any known exploits? (Score:2)
It should be easy enough to write a program to check to see if any archived mail has the extra keys.
If people wouldn't use closed source encryption... (Score:2)
When I first looked into PGP, I first downloaded PGP from MIT. I noticed that the source code wasn't available. So I did a little more looking around.
And I found the International version at The International PGP Home Page [pgpi.org]. Grabbed the Unix PGP50i source code [pgpi.org], compiled it and it works fine. When the bug in the randomness generator was found, I just patched it and recompiled!
BTW, if you are looking for all kinds of cool encryption source code for Linux, go to munitions [polkaroo.net].
Called Them (Score:2)
If anyone else thinks they will have better luck give them a call at 888-347-3925, would love to hear their perspective.
Re:This was rumored for awhile (Score:2)
So what's the answer (Score:2)
And am I correct in my assumption that PGP remains OK as long as you don't create an ADK? Or am I misreading the message?
As to it being a stupid idea, I have to disagree. There are cases where it is important to allow someone else access to the data. For example, in business affairs. If the holder of say the secret ingredients to Drambuie (nectar of the Gods, yum, yum!) had the recipe encrypted and suddenly dropped dead, what then? If the only copy is encrypted and no-one else has the key, then the recipe is lost and the company folds.
Re:Close, but wrong on a couple of key points (Score:2)
Yes, there can be more than one ADK packet, and there can be a valid ADK packet already onboard. In both cases, (if you created the certificate with a vulnerable version of PGP) you are still vunerable.
Think of it like this:
[----------1----------]
[----------2----------]
[----------3----------]
[----------4----------]
[^^^^^xx-5-xx^^^^^]
{----------6----------}
Lines 1-4 are the key certificate information... public key, username, email address, etc. Line 5 is the cryptographic hash (think digital signature) that says "hey, lines 1-4 contain exactly the following information". In vulnerable versions of PGP, line 6 is the ADK. When someone pulls down your public key (lines 1-6) their copy of PGP checks with line 5 to make sure that the entire public key is good and untampered. Since the ADK stuff can be added in line 6 without voiding the digital signature, the certificate checks out, even if someone has added an ADK to your certificate.
Bad stuff... big brother (or your boss, or etc) can now read all the data encrypted to you from others who used this tainted public key.
---------
Re:Answers about GnuPG (Score:2)
As I understood the problem, this is not going to help. The problem is, that there could be added an ADK to a key that is in Version-4 format. GnuPG generates keys in this format as well. So, even if YOU use gnupg and see that the key of your communications partner is compromised by an ADK, _his_ software he uses to encrypt to you (e.g. some PGP for Windoze) does NOT warn about the ADK that compromises your public key on the keyserver.
Yes, you might check the keyserver again and again for your own key and revoke it as soon as you see an ADK in it there. But how do you know if your communication partner has an untampered key? You don't. And that is way Schneier asks for an additional finger print that checks the signatures, too.
To be safe from having your key possibly compromised, you have to have it in Version-3 format and that means you have to use PGP 2.6.3
or PGP 2.6.3i.
And this is different exactly how from ... (Score:2)
For instance, if my system admin put an altered PGP binary on the network which passed copies of the plaintext to a logfile, I would be at least as hosed. And it would be a lot less work for the Company. Similar exploits abound; after all how many of us actually read all of our source line-for-line?
In this case, the corrupted code came from NSI. (And you decided to trust NSI, of all people, because...?)
Re:gpg (Score:2)
when pgp went corporate, some companies wanted a backdoor to their worker's email. So this was built in. gpg on the other hand is not written with companies in mind, it was written with privacy in mind. I would be surprised if gpg had this vulnerability too.
//rdj
Re:This is worrying, but: (Score:2)
So, while it isn't time to panic, it's important to keep in mind that both ends of the channel need to be secure for the information transmitted through it to be secure. We can't be complacent just because we're using free software.
Peter
Re:This was rumored for awhile (Score:2)
This is a similar weakness to and early netscape implementation of SSL that accidentally randomized a very small portion of the intended keyspace, making it trivial to brute force.
The answer is probably in a random geneating dongle. I've seen several for around $100, targeted mostly at research lab types who need very random streams to make their research meaningful. It would be nice if someone wrote a driver for good old 2.62 classic that could take bits from one of these things.
----------------------------------------------
The war on drugs may be over soon.
On my first day in office I will pardon everyone who has been convicted of a non-violent federal drug offense - Harry Browne [harrybrowne2000.org] - Libertarian presidential candidate
We will fight for your privacy.... (Score:2)
If you recall, in the mid 90's, the Clinton administration, under the recommendations of the law enforcement community, authorized the creation of the Clipper chip with its Skipjack algorithm. At the same time, Phil Zimmerman was under intense pressure and scrutiny regarding his involvement with PGP (strong encryption not under gov't control and protected by US patents).
The Clipper chip, if you recall, came under serious fire when it was discovered that it used something called a LEAF (Law Enforcement Access Field) which, theoretically, would allow law enforcement to read communications after obtaining a warrant. It was all part of the big key escrow plan. However, the LEAF could be circumvented/forged, making it impossible for LEF personnel to read the communications. The Clipper chip all but died.
At the same time, Mr. Zimmerman faced serious problems, RSADSKI/Public Key Partners/Security Dynamics and the entire justice dept were on him like a fly on
That is...until this information regarding ADKs become public knowledge.
Now, it's an election year with the Presidency, many seats in congress, senate and top courts up for grabs. The democrats/Clinton administration have been bombarded with many incidents of "espionage". We've formed closer alliances with the Chinese (who seem to be at the heart of the allegations and a major contributer for the DNC). We've had more "secrets" stolen from us in the past eight years than we could probably count..including, supposedly, information on nuclear capability and designs, missile technology, ship and submarine design and capabilities, etc. It's been a real banner eight years for the "privacy" of the United States.
Al Gore, as Vice President, had been tasked with the country's encryption policy. It was he, I believe, who actually authorized the Clipper chip's development. It would have been him who would fought against (and then lessened) our national restriction on cryptographic exports. And, it was Mr. Gore who met with Jim Bizdos of RSADSI fame (and major contributer) on numerous occassions (okay..so did Clinton).
With the popularity of the Clipper Chip waning, why not solve your problem by going after the emerging cult standard, PGP, and introduce key escrow there. Was this how the legal action against Phil was ultimately resolved? What were the actual terms of the agreement?
With so many of us "registering" our keys on the various key servers, one has to wonder if the keys have been tampered with through the addition of the ADKs. How else have we been compromised.
And, finally, why is that this was kept under wraps until an election year that this "issue" was discovered and unveiled. How long has the commercial version of PGP (Version 5 & 6) been available?
So, we have a VP candidate touting how he's responsible for the internet, how he's all for our privacy and, of course, privacy of electronic transactions. But, if the certificates for PGP have been compromised, then what is to say that the certs issued by Verisign and others have not been compromised in a similar fashion (without the CAs even knowing it). What's to say that information regarding the generation of the keys has not been hidden in a field of the certificate (the certid???).
Remember, the RSA patent will expire next month. At that point in time, there will be zero control over the use of the algorithm. Hence, new (and legal) encryption products will become readily available. We have seen a slow erosion of the security of RSA algorithm over the past couple of years through the use of code cracking contests sponser by....RSADSI. (BTW...did you know that the Windows version of their library can only be compiled using the Microsoft compiler (unless you wanna pay for the "port")...What was the bit about the NSAKEY a little while back??????)).
There have been attacks by famous cryptographers against elliptic curves (see the www.rsasecurity.com website for their December, 1999 Cryptogram publicaton). They have stated that the EC keys with 109 bits can be cracked in a year using 12,000 processors. The article fails to mention that 160 bit keys are standard practice nor how much effort must be expended to crack a 160 bit EC key.
So, with my conspiracy theory aside, everybody has a lot to gain and/or lose with this information becoming public.
One side can claim a conspiracy to discredit the other side. The other side can say that "Mr. Privacy" doesn't really mean it (if they're smart). In the end, it is us lowly citizens that get burned as we try to keep our credit card and personal affairs private.
If anybody doubts what I have said, do the research yourself. Look back on the history of the Clipper Chip and Skipjack. Look up the presidential order that gave Gore the authority to control encryption policy (which he denied for the longest time). Look at the deals that have been made over the past eight years. Make up your own mind.
While I think the democrats have a lot of good ideas, I believe they have picked the wrong man for the job of President and, probably, VP. Do the research...then, vote your conscience.
Okay..you can call me a nut now.
Re:I was having a chat... (Score:2)
I beg your pardon? And just what exactly does it do, cook dinner and wash the dishes? Anything you write is technically copyrighted, and you are using PGP to ensure that only certain parties can access that material. Think about it.
Re:Answers about GnuPG (Score:2)
The other half is that a reliable PGP implimentation should refuse ENcrypt using a public key with unsigned ADKs.
I am pretty concerned about this, because I have to rely on SOMEONE ELSES (possibly compromised) key to protect what I say.
Or am I off base here?
-Peter
Re:Open Source at it's best--not (Score:2)
Miscellaneous Thoughts (Score:2)
So you're saying if I send you random garbage or stuff encrypted to a key you don't have for some reason, the burden of proof is on you?
Someone could possibly make the argument that you can get the files but oops! Revealing the password could incriminate me. Sorry. How about some court approved immunity for anything in there? (Keeping in mind that I could potentially be the real killers)
I've wondered if someone really sneaky could set up a dual-key system such that if you decrypt with the fake key, you get an innocent message about the grocerys and the kids and stuff and if you decrypt against the real key (cleverly hidden as something else) you get the actual message. The trick would be doing that in such a way that it could not be proved that there was any other content in the message...
Fast Factoring (Score:2)
Of course, I'm paranoid too...
Re:This was rumored for awhile (Score:2)
GnuPG not vulnerable (Score:2)
--
You CAN fix this on the client... (Score:2)
a) Alert you every time someones certificate is used if it contains any additional keys.
b) Have an option of ignoring such messages.
You still have to notify the author that he is using a compromised certificate so the problem isnt entirely solved but it will be clearly visible.
This was rumored for awhile (Score:2)
Re:Why key escrow? (Score:2)
I apologize for my comment. It was meant to be sarcasticly funny. Too many people are taking it seriously.
My whole point was that cops can enter a building, if necessary, without a key. What the government and law enforcement agencies are saying by asking for key escrow is that they just don't have enough brute force to break the encyrption as easily as they can break a door down.
I think the analogy is a good one because encryption and doors and both things we used to keep people out of things we want. The differnece is in how hard they are to break. Should the government just force us to use weaker encyrption rather than key escrow (i.e. a normal door instead of giving them a key to your house).
What would they do if I had a hardened concrete and steel bunker instead of a house? What if that started proliferating and became the defacto standard. Do you think law enforcement agencies would stand for that? Would they make you build weaker buildings or give them a key?
Why key escrow? (Score:2)
If the cops want in my e-mail bad enough, they don't need a key -- they can break my encryption.
Re:gpg (Score:2)
No, it doesn't! PGP uses proprietary patented algorithms. GPG doesn't, never has and never will. THAT'S why it's superior to PGP. The only problem with GPG is that it should only be used under "proper" operating systems (e.g. any version of UNIX).
NONSENSE! GPG is released under the GPL. You can port it to any operating system you want. Why don't you check your facts before posting to this site? Oh, I forgot, this is
Re:Am i missing the point of PGP (Score:2)
ya know (Score:2)
EVERYONE'S ALREADY FSCKING DOING THAT!!!!
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
Speaking of stupid ideas .. (Score:2)
Then again, secret police aren't a particularly brilliant idea either
Re:A couple questions for Mr. Simpson (Score:2)
I'm going to direct this at Mr. Simpson as he seems to be greatly involved in this discussion. I've been involved with PGP for years - I have no official involvement with NAI. More than happy to answer questions though:
In your opinion what is a good possible solution for this?
Apart from not introducing this devils-work "feature" in the first place? ;)
Seriously, there may not be a nice answer. Erm, the first thing to do would be check every keyserver and let people know that they have ADKs. Secondly, release future versions with "Encrypt to ADK" off by default. Thirdly, change the protcol so that ADKs are part of the signed/hashed packet.
Is NAI likely to release a patch?
Probably. May be easier to fix v7 and offer free upgrades to this version for existing customers. This would allow you to easily identify users who are still using versions that are "vulnerable". I doubt they'll do this though - that would cut revenue :(
What about a new version which does not include the ADK feature? I can also see how this might be a desired feature for corporations who want to use the ADK's for thier intended use. Is it likely NAI would release a kludge in a vain attempt to keep this feature in the code?
Yes, they'll probably keep this feature. I think the last couple of bugs (including the v5 randomness bug) have done a lot of damage to PGP's reputation, which is very sad.
What is your opinion of NAI and do you think they'll do the "right" thing?
I have a lot of respect for Phil and Will Price. But this is a financial decision, we'll see. If they don't do the right thing, then I'll be sure to broadcast it from the rooftops!
Obviously with the growing popularity or PKI this can be seen as a good thing or a bad thing. Good in the fact that it exposes an inherent flaw in public key cryptography and might make some people seriously think about the implications of a public key infrastructure.
It's not a problem with public key crypto though, it'ts just an awful implementation!
Bad in the fact that a widely used version of PGP has a potentialy serious hole in it. I wonder how long the NSA has known about this one.
Should be fairly easy to see if someone has exploited the bug - just check all keys on the keyserver.
I suppose I had better update my PGP FAQ [clara.net] now!
Cheers, Sam
Re:Open Source at it's best (Score:2)
Bzzzzzzt. Wrong. PGP is open source. See for example www.pgpi.com and download your own copy..........
Re:Read the entire analysis (Score:2)
No it doesn't GPG ignores packet 10 - it doesn't know how to encrypt to ADK's!
GPG keys are vulnerable, but only when being encrypted to by NAI PGP implementations.......
Re:gpg (Score:2)
I wrote: GPG ... uses the same ciphers (and more...) that NAI/PGP uses.
You wrote: No, it doesn't! PGP uses proprietary patented algorithms. GPG doesn't, never has and never will. THAT'S why it's superior to PGP.
PGP v5 onwards has implemented CAST & 3DES and DH/DSS as the asymmetric cipher - all non-proprietary. You may be refering to PGP v2.x - but that version doesn't suffer from these ADK problems and is thus totally unrelated to this current discussion...
I wrote: The only problem with GPG is that it should only be used under "proper" operating systems (e.g. any version of UNIX).
You wrote: NONSENSE! GPG is released under the GPL. You can port it to any operating system you want.
Have you ever used / installed GPG? If you read the documentation and source code is clear and obvious that GPG needs a decent source of randomness. GPG shouldn't be used on WIN32 for example because there is no suitable source of crypto strength randomness.
You wrote: Why don't you check your facts before posting to this site? Oh, I forgot, this is /. Never mind.
Coming from someone you clearly writes from a position of gross ignorance?
PS: Read my writings on GPG/PGP at: www.scramdisk.clara.net/pgpfaq.html if you doubt my credentials.
Re:Sue Him ! (Score:2)
Mind you, he'd have to survive assassination by the CIA first ...
Secrecy: we need privacy and protection from THEM (Score:2)
Re:You just thought you were safe! (Score:2)
Crypto ain't easy folks.
Re:Look at the name (Score:2)
secondly, while I'm not a crypto-scientist, wouldn't it be safer to use double-encryption? sure, the first layer might be computable in finite time. but unless you give some clues about what the 2nd layer is (could even be rot13-hacked-and-patched), they'd have to try 'opening' that opaque mess with every known crypto alg. pretty time consuming.
I've often thought of changing pgp in small and subtle ways (maybe some grind algorithm that uses a file that is present on my system and the destination system) and unless you had access to the ACTUAL source/binary that was used to en/de crypt, you'd have almost no hope in getting plaintext back.
but like I said, I'm not crypto guy. but to me, using STANDARD sourcecode for crypto is just asking for problems. with unique peer-to-peer matching of specially modified pgp programs, I would surely sleep better at night.
...until they came knocking on my door after midnight, that is.
--
Re:This was rumored for awhile (Score:2)
--
Rebel without a clue (Score:2)
ADK flag in PGPKeys (Score:2)
Would checking this field before using someone's public key guarantee that there was no ADK attached to that key or does this vulnerablility mean that the flag won't be set?
I was having a chat... (Score:2)
Disclaimer: I need sleep. Excuse me for referring to the wonderful poster of this topic as "this kid" and excuse me for anything else I say that is nutty. I have great respect for "this kid" and how he's helped us all see the light.
...About this, when something occured to me. Now, people here have alredy suggested suing this kid under the DCMA, but it seems so appropriate an analogy to the MPAA case, it's scary.
Allow me to explain:
In the MPAA vs 2600 case, it's the same thing. 2600 didn't do anything, just reported it, like this kid. Yet they are successfully sued. Not only that, but this security hole that's being pointed out in PGP was clearly found (or at least researched) by the decompiling of the PGP source and reverse-engineering it's storage specs, right?
Even if some of those specs are public, certainly the fact that PGP works this way is not published anywhere (previously) and someone had to "hack" this system to get the info. Clearly illegal behaviour under the DCMA under any circumstance.
It's making me wonder whether we'll ever be able to report bugs that involve anything more than cursory examination. This kid went all the way, decompiled the program, posted every detail about how to determine if your system is vulnerable, how to fix it, etc, etc... and although he's doing EVERYONE a service, it's illegal to have helped like that. No one's going to sue him, I'm sure, but the point is, he broke the law.
"Life's gunna' suck when you grow up -- it sucks pretty bad right now."
I can't wait till Microsoft sues someone for revealing a security hole in Windows...
Re:Hold on (Score:2)
I you use an old V3 RSA key (the ones that PGP 2.6 creates), then there is no way they are inadvertantly encrypting stuff that an adversary can read (while thinking it is to you).
Ir you are using a new-style key (v4 of any of the two crypto algorithms), then your analysis is correct. Someone with the broken software may inadvertantly send mail thinking that it is only readable by you, when in fact it is readable by anyone who tampered with their copy of your public key.
This is very much worth knowing with all of the misguided "I use GPG so I am safe" posts floating around. Only old V3 keys are safe from other peoples' bunk software.
Stand back... Squint... (Score:2)
From the authors original message:
*PGP-2.6.3ia UNIX (not vulnerable - doesn't support V4 signatures)
*PGP-5.0i UNIX (not vulnerable)
*PGP-5.5.3i WINDOWS (VULNERABLE)
*PGP-6.5.1i WINDOWS (VULNERABLE)
*GnuPG-1.0.1 UNIX (not vulnerable)
Well, call me a zealot, but I think I see a pattern emerging...
The REAL jabber has the /. user id: 13196
How wide spread is the problem? (Score:2)
Re:Question (Score:3)
Only if somebody gets ahold of your public key while you're not looking and modifies it to include the additional decryption key.
Extending the situation, does this problem have any effect if keys are exchanged via some secure channel, where no potentially untrusted third party has access to the keys (and the chance to add an ADK to them)? So, don't trust the keyservers (which I never use) and you'll pretty much be OK as long as you get the public key directly from the person it belongs to?
Sure, so long as that person keeps perfect control of the key. However, if he goes away for the weekend and a spook enters his house and modifies your public key on his machine, you're hosed.
...phil
ADK: Retroactive Detection (Score:3)
ADKs *have* to leave additional encrypted content within the final package--somewhere, they've got to leave the decryption key in a detectable form for an attacker to come in and use to decrypt the one-time 3DES/Twofish/Other Symmetric Cipher Key. Now, it's possible that this internal key material could be stripped from the entire message and a valid hash reconstructed, much as the ADK can be added to a key without changing the overall key hash. But this would surprise and disappoint me--at that point, intent becomes a real question.
I have not intensively analyzed the PGP block format--I've been too busy working on SSH as of late--but it's necessary that *something* new is going to be added to the overall package, and that it's is going to be detectable, possibly without decryption, possibly without even the original public key. Whether it's strippable or not is a question mark, but people shouldn't be saying this is an invisible attack. It can't be.
Brutal, yes. Invisible, no.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Re:That's why I'm part of the GNU Generation. . . (Score:3)
From what I can make of the section regarding GnuPG, it doesn't warn about the presence of the ADK. However, it places but one session key in the cryptogram, a key only recoverable using the user's private key.
But if you get a contaminated version-4 public key, GnuPG will not warn you about it. You should check any and all public keys that you use as decribed in the article. I'm sure the GnuPG team will not be long in adding functionality to do this automatically.
--
"Where, where is the town? Now, it's nothing but flowers!"
Re:Stand back... Squint... (Score:3)
If you're referring to the fact that the vulnerable versions of PGP were tested running on Windows, you're not seeing a pattern. PGP-5.5.3i and PGP-6.5.1i running on Unix are just as vulnerable.
Hold on (Score:3)
"the sender who is responsible for encrypting to the ADKs, not the recipient."
Thus, if someone with a broken version of PGP sends me encrypted email, they might also encrypt to an adversary. Am I missing something?
Response from a PGP engineer (Score:3)
We're looking into it. I can't say much more than that at this point. As soon as more information is known, I will post it as a reply to this thread. Hopefully, you'll see some official word on it here soon.
-- Rob
Re:Open Source at it's best (Score:3)
GPG, the GNU equivalent of PGP _is_ open source, and does not have this vunerability.
As for the police here in the UK, thats a whole other story, and if you ask me Mr Straw has no idea what problems he is creating for the police in the long term with his RIP bill either... but that's another story for another day.
A couple questions for Mr. Simpson (Score:3)
In your opinion what is a good possible solution for this? Is NAI likely to release a patch? What about a new version which does not include the ADK feature? I can also see how this might be a desired feature for corporations who want to use the ADK's for thier intended use. Is it likely NAI would release a kludge in a vain attempt to keep this feature in the code? What is your opinion of NAI and do you think they'll do the "right" thing?
Obviously with the growing popularity or PKI this can be seen as a good thing or a bad thing. Good in the fact that it exposes an inherent flaw in public key cryptography and might make some people seriously think about the implications of a public key infrastructure. Bad in the fact that a widely used version of PGP has a potentialy serious hole in it. I wonder how long the NSA has known about this one.
How appropriate this quote of yours seems.
"Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."
-- Sam Simpson, July 9, 1998
LiNT
Read the entire analysis (Score:3)
Re:ADK? Disturbing. (Score:3)
I just looked in PGP Help. Here's what the item on 'additional decryption keys' says:
Re:So just use "authorized" keys. (Score:3)
ARRGH! Wrong!
This is a hole, a bug, a failiure. It's easily countered by including ADK information in the hashed/signed portion of the key.
This discovery means that EVERY key on public key servers is potentially broken. Hell, any naive users key could have this ADK packet and not even be aware! Using "authorised" keys, whatever that means, isn't a solution.
Sounds like a good job for a virus or IRC bot (Score:3)
It can't really be a virus or IRC bot, but why not a snipped of open source code. Get it out, and everyone scan every key they hold. Scan every key that you know you've put somewhere. Scan every key you use to send. Scan every key you touch.
For that matter, wrap it in with GPG.
While we're at it, send upgrade notices back to anyone who uses the wrong version of PGP to send us mail. Stomp it from the face of the Earth.
So just use "authorized" keys. (Score:3)
I agree this is a problem, but it doesn't render PGP useless.
Just make sure, when you get someone's public key, that it comes from an "authentic" source.
Sue Him ! (Score:3)
Worse even, sites such as Slashdot freely link to this information, destroying a successful business model (namely e-commerce) !
Don't let him get away with it, protect our right to profit !
And while you are at it, imprison all mathematicians who might find ways to break our precious cipher systems by finding a way to factor large numbers
(Sounds stupid, but wouldn't there be legal action in such a case ?
Re:Look at the name (Score:3)
While there haven't been any real structural attacks to PGP, up until this, it is theoretically more likely that structural attacks will work against PGP than standard crypto. Perhaps the NSA has already found a way? Also, traditional PGP uses the RSA encryption algorithm, which, if you follow Distributed.net, gets brute-forced regularly. If you really are scared of the government reading your email, then I doubt PGP will put your fears to rest.
Re:So what's the answer (Score:4)
The problem is that anyone can add an ADK to a public key without affecting the key's fingerprint. In other words, it is perfectly possible for someone to set up a keyserver that adds an ADK for themselves to each key uploaded, and no-one will by any the wiser, unless they examine the key closely.
How they get their hands on the mail encrypted using those keys is of course outside the scope of this post.
Idea: A company could set up an internal auto-ADK-adding keyserver for its employees to use, and of course they have access to the outgoing mail spool.
--
"Where, where is the town? Now, it's nothing but flowers!"
Re:GPG? (Score:4)
GPG [gnupg.org] is based on the OpenPGP standard ( RFC 2440 [isi.edu] ) which doesn't, AFAIK, include "Key Escrow" or "ADK". PGP [pgp.com] seemes to have "added" this feature, perhaps this is what the mean by "multiple recipents" in the E-business product. [pgp.com]
Of course I could be wrong, but that's the way it looks to me
Trust goes one way (Score:4)
This sentence is meaningless. Trust goes only one way. It doesn't mean anything if someone you don't know has signed a key.
I only added signers of keys to until the database was 4000 keys or so.
You're going the wrong way. You should trace the web of trust by looking for keys that are SIGNED BY that key, not keys that SIGN IT. Yes, I know, it's a little more difficult to find all the keys signed by a particular key. You need to download the entire database for that.
The only solution to this is a certified key authority.
According to your logic I could discredit the certificate authority by creating a bogus key and signing the CA's key with it...
----
Re:This is no surprise (Score:4)
Not new or secret (Score:4)
There was a great deal of arguing and discussion in cryptographic circles when this came out. The gist of it is that when you email something from work, you're employer can get sued for it, so employers want the capability to read that email, they are legally entitled to in the US. So they added "enterprise" or "corporate" support to PGP. In the business world it makes more sense then you think, they can also recover messages if you're harddrive crashes and takes your secret key away. If PGP is to ever take hold in that market, and PGP is about making money anymore, then it needs this so called ADK feature.
DO NOT FEAR. KEEP USING PGP and GPG if you're one of the 2% who do! If they include the ADK within the key signature then the problem goes away and it works as designed. ADK is a good thing because it makes the product usable in markets it would otherwise never make it. My fear is that this will be treated like Clipper was, and for some reason people get paranoid about having encryption where an authoirzed third party can decrypt your transimition so the proper thing to do is keep using no encryption because that is some how better.
As a former one of the original cipherpunks and a crypto freak I'm also beginning to come around on escrow and key certifcation services. I've built a key database starting with my keys and the linux kernel key. I only added signers of keys to until the database was 4000 keys or so. "The web of trust" doesn't work, there are lot's of fraudulent and dead keys in there and they are signed by someone who was trusted enough to sign the kernel key, or someone who was trusted enough to sign the key of one of the signers of the kernel key. I only went out 3 hops from the kernel key when I was making the database. If you play 6 degrees of Kevin Bacon with PGP keys and start with Linus and the kernel key you get to a bunch of trash really quickly. (this was all done with keyserver.net) Example: Gandhi (yes, at nonviolent.org) has signed Dave Del Torto's key who has signed Theo Ts'o's key who is a kernel hacker and has signed the Kernel key. There is nothing that prohibits anyone from signing another key, so essentially you can't trust a key simply because it was signed by somebody. The web is a direct graph and the arrows point the wrong way, you can only trust keys you trust enough to sign and you can't draw any conclusion from someone else's signature being on a key. There is also a tremendous amount of garbage in the web of trust.
The only solution to this is a certified key authority. The problem with that is they are a business (better than a governement agency) and they will want to use ADK to cover their ass. I think the risk can be managed to a reasonable point by having multiple companies with checks and balances. I would use a key authority if, a) it was seemless and all my email was encrypted with said key and b) key authority couldn't decrypt my key but a 3 party might be able to with a court order. I still wouldn't use it for encrypting my confessions of sexual peccadillos or my plans to over throw the government but it would be more than acceptable for email which is largely unencrypted now. (So not just can the govenrnment read it but your neighbors, your employer and foreign governments can all read it too.) As it stands, if I was told by a court to decrypt my email and there wasn't an ADK capability, I would go to jail for contempt until I did, so when it comes down to it, if some one wants to forcably read your email and a court agrees you're going to lose that battle either by decrypting it or by going to jail and testing your will.
This isn't a real problem (Score:4)
It's only keyservers that this could occur on. Personally I keep mine on my web pages [a2000.nl], anyone who wants to mail me securely uses that, or the one I mail them...
Rule: Only use keyserver keys for verification of an unknown source, and even then, if it's important don't trust it...
EG I get the CERT key from their web site [cert.org]
It's your security people, don't give it to someone else...
Re:GPG? (Score:4)
Can we ask someone within PGP? (Score:4)
Hans Voss
---
Re:GPG? (Score:4)
ADK? Disturbing. (Score:4)
This is no surprise (Score:4)
PGP 5.x was, is, and will continue to be a screwup.
They deliberately changed the command line interface to break every PGP-interoperable tool out there.
They released the Windows version months before the UNIX version.
When they finally were releasing the UNIX versions, they were binary-only.
Eventually, they got around to releasing the source code to the world. This was supposedly because of legal concerns, but that explanation doesn't really hold water. The binaries were released and restricted to the U.S. The source code was written in book form and exported, then to be scanned in, which was legal. Of course, the binaries made it out of the U.S. in about 45 minutes. The source code could have easily been released and restricted to the U.S., but wasn't. This didn't sound right at the time either.
They deliberately broke interoperability with older versions of PGP, which in effect forced people to upgrade. Because they didn't release source code, people were upgrading with binary-only versions.
Anybody searching the Cypherpunks archives from around the time PGP 5.0 was released can find several large threads on these topics.
So, again, it doesn't come as a surprise that PGP Incorporated is a government shill organization, particularly after they joined the KRAp.
Screw them. They and the government can go fuck themselves.
Re:Can we ask someone within PGP? (Score:4)
Will Price, Director of Engineering, PGP Security, Inc. has been alerted and is looking into it - he expects to report back to PGP-USERS mailing list Thursday.
Re:GPG? (Score:4)
This doesn't apply at all to GnuPG - it doesn't recognise the ADK packet (and it shouldn't - RFC2440 specifies that this packet is simply "placeholder for backward compatibility".
This is worrying, but: (Score:4)
GNUPG [gnupg.org] isn't affected - so those of us who like a software free-as-in-speech don't have an problem.
It can only affect you if you get a key from an untrusted source. For most /.ers this won't be an issue.
So basically, don't panic just yet. Of course, this will no doubt start a number of 'many eyes of open-source' arguments.
Would Updating Keyservers Help? (Score:5)
Wouldn't the impact of this vunerability be reduced significantly if the various public keyservers were reconfigured to reject keys uploaded with unsigned ADK's?
Re:ADK? Disturbing. (Score:5)
Here is the exploit sequence: you issue a PGP certificate, containing your public key. You may be not be running a version of PGP with the bug, it doesn't matter. Joe Evil attaches another public key to your certificate as an ADK, and passes it around. Someone who is running the vulnerable PGP uses your certificate to encrypt a message to you. However, they *also* make a copy encrypted with Joe Evil's public key! And they won't even know it unless they examined your certificate manually. Now Joe can read their message.
So the problem here isn't that PGP is attaching an ADK, but rather that someone could later attach an ADK and the tampering would be not detected by someone using the certificate to communicate with its issuer.
--
Explanation of the problem (Score:5)
The reason that this vulnerability in PGP is serious is that you can't fix it by updating your copy: you have to ensure that everybody who might send you encrypted messages has a copy of PGP without the ADK bug. This is difficult, especially when you don't know who your correspondants are going to be ahead of time.
Here is a summary of Ralf's paper that I wrote while reading it yesterday:
More followup: I've found the bug in the PGP-6.5.1i-beta2 source code. I'm fairly sure it will be identical in all the other vulnerable versions.
In file libs/pgpcdk/priv/keys/keys/pgpRngPub.c, I see two functions: one called ringKeyFindSubpacket(), which finds a subpacket from a self-signature packet, and ringKeyAdditionalRecipientRequestKey(), which uses ringKeyFindSubpacket() to search for ADK subpackets.
ringKeyFindSubpacket() is declared as follows:
PGPByte const * ringKeyFindSubpacket (RingObject *obj, RingSet const *set, int subpacktype, unsigned nth, PGPSize *plen, int *pcritical, int *phashed, PGPUInt32 *pcreation, unsigned *pmatches, PGPError *error);
In particular, the "phashed" parameter is used to return whether the subpacket was in the hashed region. Now, looking at the call in ringKeyAdditionalRecipientRequestKey() I see this:
krpdata = ringKeyFindSubpacket (obj, set, SIGSUB_KEY_ADDITIONAL_RECIPIENT_REQUEST, nth, &krdatalen, &critical, NULL, NULL, &matches, error);
...the "phashed" value isn't checked (or even asked for)!
Ok - it's an obvious implementation bug, and the bug itself should be easy to fix. I won't comment on the wisdom of designing in ADKs in the first place; the problem now is, how do we get everyone to replace their vulnerable copies of PGP? And, since that won't ever happen completely, how do we minimise the remaining problem?
It should be easy to spot keys that have been tampered with: use gpg --list-packets and look for ADKs in the unhashed section of the self-signature. You can also check to see whether you are receiving messages that have been encrypted to more than one recipient: look for multiple session key packets.
Finally, I recommend that regular sweeps are made of the public key servers for keys that have been tampered with.
Close, but wrong on a couple of key points (Score:5)
In short, the exploit sequence is as follows:
Alice creates a PGP certificate. This is composed of her public key plus a bunch of other "packets" containing info like UserID, etc. One of these packets is essentially a checksum, containing a signature of the previous packets. In NAI PGP version 5, the ADK packet is included OUTSIDE of the checksum (so you can attach an ADK packet without affecting the checksum (and thus without generating an error message that the key has been tampered with). Alice then uploads her PGP public certificate to the pgp root server.
Carol wants to read any messages to Alice, so she goes out, pulls down Alice's certificate, and adds an ADK packet featuring her own public key. Then Carol uploads the new copy of Alice's key. Because the ADK packet is not included in (not checked by) the signed hash packet, this addition is not noticed as making the certificate invalid.
Now Bob decides he wants to send an encrypted message to Alice, so he pulls her public key from the pgp root server. He gets the latest copy, which is the version with Carol's ADK packet. So when Bob encrypts a message to Alice, it's just like he selected to encrypt the message to Alice and to Carol. So Carol can then intercept the email and decrypt it using her own private key.
---------
Lawsuit (Score:5)
I'm going to file a lawsuit against Bruce and Slashdot and anyone who links to Slashdot and anyone who reads the article and anyone who points at or otherwise refers to a person who reads the article. In fact, Bruce himself is circumvention technology, so I'm suing his parents, too, along with the major airlines, both of which have distributed Bruce.
Re:This is no surprise (Score:5)
Point-by-point:
1) "PGP 5.x was, is, and will continue to be a screwup". Your opinion, obviously. I agree some things could have been better with it (especially the Unix version).
2) "They deliberately changed the command line interface to break every PGP-interoperable tool out there." No. *I* deliberately changed the command line interface (with much deliberation) for two reasons: Once Unix development started, we were on a very tight schedule, as the Windows and Mac versions had already been released (see blow). The primary goal was to make it possible for Unix to decrypt the new key formats as quickly as possible. There was not time, under the schedule, to reimplement the 2.x command line item-for-item. Given that we were creating a security application, my opinion was that it was much better to create a new interface and break everything than to try to emulate the old interface and perhaps subtly break other things without complaint. The secondary goal was to improve the interface to be more Unix-like and less DOS-like (note, for example, that under 2.6.2, you can't do something like "pgp -ea president@whitehouse.gov *.txt"). In the end, I suspect my interface failed; I know I didn't have time to think about it, design it or get the input I would've liked. So, it is technically acurate that the change was "to break every...tool out there," but the intent was to prevent subtle security flaws in programs that interoperate with PGP.
3) "They released the Windows version months before the UNIX version." True enough. We were a startup, in those days, and, if you look at Wired Magazine from the same time period, youll find we did significant layoffs at the company around that time. As 5.0 was rolling out, PGP, Inc. was realizing that it didn't really have enough funding to keep going as an independent entity. As a result, we didn't have any resources to devote to Unix. Windows and Mac were our focus because that was what was needed for the corporate clients we needed to keep the business going. Once Windows 5.0 shipped (I was a developer on that, as well), work was begun on 5.0 for Unix. I was the only person on the non-crypto team (who were now busy working on 5.5) who had any knowledge of Unix, so I got to do it all by myself, with essentially no other resources. So, yes, it came out later. We didn't have the people to do it any sooner.
4) "When they finally were releasing the UNIX versions, they were binary-only." In July of 1996, we published the first source-code books, containing the PGP 5.0 source code from the late June releases of 5.0 for Windows and Mac. Our intent with these books was to make the source code available for international review within the constraints of US export law at the time. It took about a month to get them together, as we had to write code to format the books correctly, etc. With every subsequent book, it took less time for the code to be released, as we improved the process. In the July book, we included the "alpha" version of PGP 5.0 for Unix that I was developing, at the time. It had a lot of flaws, but let people see the code. This was scanned in and became available online in late July or early August (if memory serves). Once the final Unix version was released, the code was available in the next source code book. I know we discussed publishing an addendum with the 5.0 Unix code, final version in it, but I don't recall if that happened. The 5.0 Unix source-code book may have been delayed because PGP, Inc. was running out of money, that fall. As I recall, the code itself was completed in September, but it may be true that the code was not actually published for some months, afterward. Again, this was not due to a conspiracy, but due to a lack of funds.
5) [Long rant about publishing the books not making sense]. We did not publish the source code electronically for very specific export-control reasons. At the time, it was illegal (punishable with jail time) to let that type of stuff out of the country. We felt that, as a company, we had a big, fat target on us, and we had to do everything in a completely legal fashion. As I said in number four, I agree that the Unix source code didn't come out as quickly as it could, but that had more to do with a lack of funds than anything else.
6) "They deliberately broke interoperability..." The answer to this one is really simple: Patents. We wanted to release a completely freeware version of PGP. We couldn't, as long as RSA was a requirement. Therefor, we had to move the product off of RSA.
Finally, you complain that "PGP Incorporated is a government shill organization..." Technically speaking, "PGP, Inc." doesn't really exist since they were purchased by Network Associates, Inc. in December of 1997. I'm going to assume what you're trying to get across here is that, earlier in 1997, PGP, Inc. was a government shill organization (as evidenced by its poor support of Unix, apparently).
This was an accusation frequently leveled against us at the time, but which we were not permitted, as employees, to counter. I've never really said anything about it, before, and certainly slashdot is not the kind of place where this is going to be widely read an understood, but:
PGP, Inc. was a lot of things. It was a startup with too much money, too fast, that burned that money too quickly on unimportant things. It made a lot of business decisions, some which I agree with (making Windows a priority, for example) and many of which I didn't. It was quite amusing, at the time, to see how everything we did was considered evidence of a government conspiracy. My wife was the build mistress, and she'd make some trivial change to a README and the next thing you'd know there would be people on Usenet analyzing the wording for proof that the NSA was controlling us.
In the end, PGP, Inc. lasted about a year and a half. I joined in November, 1996, when they had gotten their first financing. Like a lot of other people, I took a significant pay cut to come work on PGP, because of my love of the product and desire to help create a product that would help people protect their privacy and resist tryanny. Almost every employee there (and certainly all the engineers) were there for similar reasons. We did a lot of things that I think we'd change, in retrospect. But I personally lost thousands of dollars in lost wages working for PGP (and got basically nothing in the sale to NAI). The reason all of us were there was to build a company that could take encryption to the masses. The strategy we chose was to do that by selling a product to large corporations.
You may have complaints about what we did. I personally was never happy with PGP 5.0 for Unix, and can understand why others (especially those who actually paid for it) might have complaints about it. But to say that we did it in concert with the government or to aid the government in any way is not just ridiculous, it's offensive. Staring a company from the ground-up is hard, and it's not surprising that we made mistakes. But they were all honest ones.
You're too late (Score:5)
MIB
Re:So what's the answer (Score:5)
If I read this correctly, only some versions of PGP have this problem with the ADKs. So does anyone know which ones have this problem? Or (better) which ones don't have this problem.
From the authors original message:
PGP-2.6.3ia UNIX (not vulnerable - doesn't support V4 signatures)
PGP-5.0i UNIX (not vulnerable)
PGP-5.5.3i WINDOWS (VULNERABLE)
PGP-6.5.1i WINDOWS (VULNERABLE)
GnuPG-1.0.1 UNIX (not vulnerable)
And am I correct in my assumption that PGP remains OK as long as you don't create an ADK? Or am I misreading the message?
NO! The problem is that ANYONE can create an ADK on the end of your existing PGP public key!
Re:ADK? Disturbing. (Score:5)
ADK has been a part of the NAI PGP implementation since v5 (e.g. 3 years ago).
There was a lot of arguing about including this feature, it's been documented in the user manual since v5, it's been talked about on newsgroups etc and it's been documented quite widely.
One saving grace is that the PGP standard (RFC2440) DOESN'T include this feature - so the problem should be fairly confined to users of NAI/PGP.
Again an example of Free OSS being better than the commerical alternatives? ;)
I'm really surprised that anyone who follows PGP to any degree has failed to notice? Anyway, it's documented in my PGP DH vs PGP RSA FAQ at: http://www.scramdisk.clara.net/
Rgds,
Sam
Answers about GnuPG (Score:5)
> -----Original Message-----
> From: Adam Back [mailto:adam@cypherspace.org]
> Sent: 24 August 2000 15:12
> To: Ross.Anderson@cl.cam.ac.uk
> Cc: ukcrypto@maillist.ox.ac.uk; ietf-openpgp@imc.org
> Subject: Re: Serious bug in PGP - versions 5 and 6
>
>
>
> Ross Anderson writes on uk-crypto:
> > Ralf Senderek has found a horrendous bug in PGP versions 5 and 6.
> >
> > [...]
> >
> > He's written a paper on his work and it's at
> >
> > http://senderek.de/security/key-experiments.html
> >
> > Since NAI joined the Key Recovery Alliance, PGP has supported
> > "Additional Decryption Keys" which can be added to a public key.
> >
> > The sender will then encrypt the session key to these as well as to
> > your main public key. The bug is that some versions of PGP respond
> > to ADK subpackets in the non-signed part of the public key data
> > structure. The effect is that GCHQ can create a tampered version of
> > your PGP public key containing a public key whose corresponding
> > private key is also known to themselves, and circulate it. People
> > who encrypt traffic to you will encrypt it to them too.
>
> Amazing, and really unfortunate. Those of us who invested large
> amounts of effort in ensuring the ADK subpackets were not included in
> the ietf openPGP standard can be pleased we succeeded -- otherwise
> gnuPG and other implementations may now also have contributed to this
> risk. As it is gnuPG doesn't honor ADK requests, and all the rfc2440
> says about them is:
>
> 10 = placeholder for backward compatibility
>
> At the time I was suggesting that if PGP really must insist on
> creating software to escrow communications (the primary argument being
> that people didn't want to lose access to the stored mail as opposed
> to being able to have designated third parties snooping mail in
> transit) they should use storage key escrow.
>
> My main premise was that communication key escrow is too risky because
> an outside attacker gets the plaintext:
>
http://www.cypherspace.org/~adam/cdr/
"Keys used to encrypt email which is transmitted over the Internet are
more valuable to an attacker than keys used to encrypt stored files
because of the relative ease with which an attacker can obtain copies
of emailed ciphertext. Stored encrypted files in contrast are
protected by all the physical security systems the company is relying
on to protect it's paper files, plaintext data stored on disks, and
backup tapes. [...]"
There was also lots of political discussion of how unwise it was for
PGP to create a escrow infrastructure which could as easily be used by
governments as by SEC companies to archive their employees
communications.
And people quoting Phil Zimmermann a few years earlier complaining
about ViaCrypt's PGP4 for business variant which had "escrow" in the
form of a third party "encrypt-to-self" config file setting.
And I believe I recall the NSA or some other US government body
picking up on the CMR / ADK mechanism and holding it up as evidence
against the claim that key recover was complex
this works".
> It's of scientific interest because it spectacularly confirms a
> prediction made by a number of us in the paper on `The Risks of Key
> Recovery, Key Escrow, and Trusted Third-Party Encryption'
> that key escrow would make it
> much more difficult than people thought to build secure systems.
Yes. It really highlights the truth in the statement about the
new risks introduced by adding key escrow.
Adam