Debunking the PGP backdoor myth for good. [was RE: Hypothesis: PGP backdoor (was: A security bug in PGP products?)]

Dave Korn dave.korn at
Mon Aug 28 09:21:06 EDT 2006

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.
> 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

  Examine the instructions at

"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

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

  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

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.


  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

  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.

Can't think of a witty .sigline today....

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list