On 24 August 2006 03:06, Ondrej Mikle wrote: > Hello. > > We discussed with V. Klima about the "recent" bug in PGPdisk that > allowed extraction of key and data without the knowledge of passphrase. > The result is a *very*wild*hypothesis*. > > Cf. http://www.safehack.com/Advisory/pgp/PGPcrack.html > > Question 1: why haven't anybody noticed in three months? Why has not > there been a serious notice about it?
Because it is completely incorrect. Utterly wrong. This was explained on this list just a couple of days ago, look for the thread "A security bug in PGP products?" in the list archives. > According to the paper, both "standard" .pgd and self-extracting SDA > (self-decrypting archives) are affected. Systematic backdoor maybe? No, the paper is wrong. They aren't affected, you can't break the encryption on them, and therefore there is no backdoor. > Possibilities: > 1) it is a hoax. Though with very low probability. The text seems to > include a lot of work and makes perfect sense (REPE CMPS, all the > assembly), i.e. we suppose it is highly improbable that somebody would > make such hoax. It is not a hoax. It is the work of an incompetent. Like many of those who invent perpetual motion machines, he genuinely believes that what he has done is correct, but it isn't. Unfortunately, but also very much like many of those who invent perpetual motion machines, when this is pointed out to him he assumes that everyone else is either stupid or malicious, rather than accept that his theory has a massive flaw which completely undermines it. > This can be either proven or disproven simply by > checking the Win program using hex editor/debugger (using an already > downloaded copy). I haven't had the time to check it yet (no Win). Actually, it can't, because the instructions he has given are not sufficient to follow. At the critical point, he says you must replace the bytes where the disk encryption key is stored. Unfortunately, he cannot tell you what to replace them with, unless you already happen to have a copy of the bytes representing that *exact* *same* disk encryption key stored *under* *a* *known* *passphrase*, and that is why the only example on his website that "works" is the one where you change the passphrase on a disk but don't re-encrypt it. He even admits that in all other cases you will "extract crap". Examine the instructions at http://www.safehack.com/Advisory/pgp/PGPcrack.html#Two_Ways_to_bypass_PGP_SDA_ Authentication ----------------------------------<quote>---------------------------------- "Two Ways to bypass PGP SDA Authentication and EXTRACT with success After spending a lot of time debugging and analyzing PGP SDA, we came up with a conclusion that we can successfully extract the contents of PGP SDA in 2 ways. 1) Modifying the contents of the address 00890D70. (Screen Capture) The modification should be done in: 0040598F |. E8 AC3D0000 CALL filename_s.00409740 At: 00409740 /$ 8B4424 0C MOV EAX,DWORD PTR SS:[ESP+C] At this point change the contents of 00890D70. After the bytes change, you will have to bypass authentication. After bypassing authentication you will be able to extract. 2) Modifying the contents of the address 00BAF670. (Screen Capture) The Modification should be done in: 0040595F FF15 90324100 CALL DWORD PTR DS:[413290] At: 004019DA /$ FF7424 08 PUSH DWORD PTR SS:[ESP+8] At this point change the contents of 00BAF670. NOTE: At this point if you change the contents of 00BAF670, you won't have to bypass authentication, it will work like a charm, and it will grant auth/extract. ----------------------------------<quote>---------------------------------- Notice the crucial phrases "At this point change the contents of 00890D70", and "At this point change the contents of 00BAF670". He gives you absolutely no information what it is that you need to change those bytes to. Well, I can tell you. You have to change them to be the value of the disk encryption key as encrypted by whatever passphrase you chose to enter. You cannot do this unless you already know the disk encryption key. In other words, if you already know the key to decrypt the disk, you can decrypt the disk. If you don't, however, you can't. Examine the writing a bit further down the page, where it says ----------------------------------<quote>---------------------------------- Accessing ANY PGP VIRTUAL Disk . (Need more testing and free time, Check Debugging Notes at the end) At this point you can add users change existing users passphrase Re-encrypt disk and do other stuff. But when you try to access the disk you will get Disk is not formatted. This is when you need to use your debugger. ----------------------------------<quote>---------------------------------- Notice how he doesn't say what you need to *do* with the debugger, so let me explain what he has skipped over: Using only your debugger, you need to guess the decryption key for the disk. Think that's something you can do with a debugger? The author has made the *exact* same error as when someone comes up with a magical compression algorithm that they say can compress absolutely any data down to a tiny size. They always get the data to compress, sure, but they always have problems with the decompression stage. They tend to think that this is just a minor bug in their decompressor they need more time to work on, but no amount of time will let them work around the fundamental mathematical fact that they've not got sufficient information in their compressed file to reconstruct the original. Similarly, this author has successfully bypassed the protection built into pgp that prevents you mounting a disk using the wrong encryption key, and has decrypted a disk with the wrong key, getting garbage out. He thinks that he has solved the big problem and now has just one small problem left to solve. However, the problem he has left to solve is in fact the exact same one he had to start with: how to decrypt a bunch of data when you have no idea of the key. All he has done is decrypt a bunch of encrypted data with the wrong key. Given that symmetrical encryption is a group, effectively he's randomised the original key that was used to encrypt the data. THIS is the take-home point:- ***** He still can't decrypt it without guessing (i.e. brute-forcing) an encryption key the exact same size and strength as the original. ***** > What do you think? Your input is welcome. All your speculation is based on the assumption that the report is correct and that therefore there must be an explanation of some sort why the problem has occurred. But the report is not correct, the problem has not occurred, and therefore there is nothing to explain. cheers, DaveK -- Can't think of a witty .sigline today.... --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]