Re: A security bug in PGP products?
On 8/23/06, Dave Korn [EMAIL PROTECTED] wrote: Given that, whatever passphrase you use, you will decrypt the EDK block and get /something/ that looks like a key, this comparison of hashes is a sanity test. If you bypass it but enter the wrong passphrase, you'll get an incorrectly-decrypted EDK, which will lead your disk to look like every sector is full of random garbage. Rather than decrypt the entire disk and run chkdsk to see if it looks sane, comparing the hashes of the passphrase is a quick and dirty way of testing if the resulting EDK is going to be the correct one. The PGP email encryption has two known-plaintext bytes for that purpose. This only honors a bad key 2^16 of the time, but ensures that brute-forcing must do a more extensive unknown-plaintext attack at that rate for any potentially-correct key. This reminds me a little of the suggestions that MACs should be truncated, although it seems to me that it's better to encrypt a hash of the plaintext. -- If you're not part of the solution, you're part of the precipitate. Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A security bug in PGP products?
Max A. wrote: Hello! Could anybody familiar with PGP products look at the following page and explain in brief what it is about and what are consequences of the described bug? 1. The disk is encrypted using a long, secure, random, symmetric en/de-cryption key. (EDK for short). 2. The EDK is encrypted with a passphrase and stored in a header at the start of the encrypted disk 3. If you change the passphrase on the disk, it simply reencrypts the EDK using the new passphrase. It does not generate a new EDK and it does not re-encrypt the entire disk. 4. Therefore the EDK itself is still the same, and if you overwrite the new header (with the EDK encrypted by the new passphrase) using a stored copy of the old header (with the same EDK encrypted under the old passphrase), you have effectively changed the passphrase back - without having to have knowledge of the new passphrase - and can now regain access using the old passphrase. The guy who wrote that page posted a thread about it a while ago, I think it was on FD or perhaps Bugtraq. His interpretation is somewhat coloured by his transparent belief that these are big corporate monstrosities and hence /must/ be evil. His website is full of significant exaggerations/inaccuracies; for instance, when he claims that you can break the decryption using a debugger, he forgets to mention that this only applies to a disk where you originally knew the passphrase and have since changed it. It's more of a usage/documentation issue, really; an end-user might believe that changing the passphrase re-encrypted the entire disk beyond their ability to retrieve it. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A security bug in PGP products?
On 21 Aug 2006, at 3:36 PM, Max A. wrote: Hello! Could anybody familiar with PGP products look at the following page and explain in brief what it is about and what are consequences of the described bug? http://www.safehack.com/Advisory/pgp/PGPcrack.html The text there looks to me rather obscure with a lot of unrelated stuff. The guy's basically confused. I wrote a long thing at the time to bugtraq with lots of detail. He's got two basic claims. The first is that if he makes a copy of a disk file, changes the passphrase on the copy, and then uses a hex editor to paste the passphrase reduction back onto the copy. Poof, the old passphrase works again. This is like saying that you can use emacs to edit a file and change 123 to ABC and then use a hex editor to change 0x41 0x42 0x43 to 0x31 0x32 0x33 and ZOMG! The change magically vanishes! As Ondrej Mikle points out, the disk hasn't been re- encrypted. If you want the disk to be re-encrypted, you press the big Re-encrypt button in panel. The other thing he did was that he found some code that basically does: if (user-types-right-passphrase) then mount-the-disk else display-error endif And then he patches out the if statement and notices that the disk will mount, but curiously is lots of random garbage. He leaves as an open problem how to make the disk readable after patching out the if statement. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A security bug in PGP products?
What they're saying is if you change the password, create some new data in the encrypted folder, then someone who knew the old password, can decrypt your new data. Why? Well because when you change the password they dont change the symmetric key used to encrypt the data. The password is used to create a KEK (key encryption key) and this in-turn is used to encrypt the folder key (which is used to do the actual data encryption.) Now in common with a lot of other systems, changing the password does not entail re-encrypting the actual data. (To do so would require waiting for it to re-encrypt. There are systems that do this, but it is a tradeoff, espeically in a single-user scenario) Personally my preferred security property (in a multi-user storage system where users can be added and removed) is that people who had access can still decrypt the stuff they had access to, but can't decrypt new data encrypted since then. I think its a good balance because that person had the data anyway, and could remember it, have backups of it etc. Another thing that can be done is to utilize an online server, which has an additional key such that it cant decrypt, but can hand it over on successful auth and can delete that key on request. Obviously the key would be combined in a one-way fashion so the server does not have to be trusted other than to delete keys on request. However the article also talks about forensics, and I think they maybe confusing something there because most encrypted content is not authenticated anyway (you can merrily switch around ciphertext blocks without triggering any integrity warnings at the crypto level). And anyway if the forensic investigator has the password, he can change anything! -- symmetric encryption keys known to others are not signatures. Adam On Mon, Aug 21, 2006 at 03:36:16PM -0700, Max A. wrote: Hello! Could anybody familiar with PGP products look at the following page and explain in brief what it is about and what are consequences of the described bug? http://www.safehack.com/Advisory/pgp/PGPcrack.html The text there looks to me rather obscure with a lot of unrelated stuff. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A security bug in PGP products?
On Mon, 21 Aug 2006, Max A. wrote: Could anybody familiar with PGP products look at the following page and explain in brief what it is about and what are consequences of the described bug? http://www.safehack.com/Advisory/pgp/PGPcrack.html The text there looks to me rather obscure with a lot of unrelated stuff. The system works as follows: a random key K is used to encrypt all the data on the volume; the passphrase is used to encrypt the key K. This design allows to change the passphrase without reencrypting the whole drive (only K needs to be reencrypted). One well-known side-effect is that if one knows K he can decrypt the data. So, if an attaker knows the password and can read your volume image at some point at time, he can decrypt the volume even if you change the password (recall that you have not changed the key). -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A security bug in PGP products?
Ondrej Mikle [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Max A. wrote: Hello! Could anybody familiar with PGP products look at the following page and explain in brief what it is about and what are consequences of the described bug? http://www.safehack.com/Advisory/pgp/PGPcrack.html It seemed a bit obscure to me at first, but it says basically: PGPdisk does not use key derived from passphrase, just does simply this: if (somehash(entered_password) == stored_password_hashed) then access_granted(); That's the REPE CMPS chain instruction (string comparison). The check can be simply skipped using debugger by interrupting the program, changing CS:EIP (i.e. the place of execution) to resume after successful check. The text probably implies that the key is stored somewhere in the PGPdisk file and key's successful extraction does not depend on knowledge of the passphrase. Nope. Well, yes, the text does imply that, but the text is seriously wrong. See my previous post for the full mechanism. (Assuming the moderator lets it through.) Given that, whatever passphrase you use, you will decrypt the EDK block and get /something/ that looks like a key, this comparison of hashes is a sanity test. If you bypass it but enter the wrong passphrase, you'll get an incorrectly-decrypted EDK, which will lead your disk to look like every sector is full of random garbage. Rather than decrypt the entire disk and run chkdsk to see if it looks sane, comparing the hashes of the passphrase is a quick and dirty way of testing if the resulting EDK is going to be the correct one. The author of the website did have this explained to him by someone from PGP corp. on FD when he first reported this, but he failed to understand it, or perhaps just refused to believe it. Bypassing this check doesn't decrypt the disk. So if you change passphrase, the disk won't get re-encrypted, just by copypasting the old bytes you will revert to the old passphrase or you can create another disk with passphrase chosen by you and use copypasting method to decrypt other PGPdisk protected with passphrase. Yes to the first one, but no to the secopnd, because when you create a disk it will have an entirely new EDK, so replacing the header block with one from a different disk will mean that, yes, you can enter the old passphrase, and yes, that will pass the hash-comparison check, but the old EDK (that you correctly decrypt with the correct passphrase) doesn't actually apply to the encrypted data on the new disk, and the disk will look like gibberish. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A security bug in PGP products?
Max A. wrote: Hello! Could anybody familiar with PGP products look at the following page and explain in brief what it is about and what are consequences of the described bug? http://www.safehack.com/Advisory/pgp/PGPcrack.html It seemed a bit obscure to me at first, but it says basically: PGPdisk does not use key derived from passphrase, just does simply this: if (somehash(entered_password) == stored_password_hashed) then access_granted(); That's the REPE CMPS chain instruction (string comparison). The check can be simply skipped using debugger by interrupting the program, changing CS:EIP (i.e. the place of execution) to resume after successful check. The text probably implies that the key is stored somewhere in the PGPdisk file and key's successful extraction does not depend on knowledge of the passphrase. So if you change passphrase, the disk won't get re-encrypted, just by copypasting the old bytes you will revert to the old passphrase or you can create another disk with passphrase chosen by you and use copypasting method to decrypt other PGPdisk protected with passphrase. I haven't checked myself if their claim is true, but it's possible. Hope that helped O. Mikle - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
