How to backdoor store-and-forward public key crypto?

So, the german and french government want to break cryptography. Now they "only" want to be able to decrypt messaging apps. If they get their law - and since there's not much sanity left in the corrupt EU this will likely happen - what will be next?

I think store and forward crypto systems are the first to come into mind, that is: PGP. Happily I am the maintainer of some nice but working play store and forward crypto software: PCP. Of course it is not PGP but uses comparable features. So, after reading the news the other day I thought to myself:

How would I implement such a backdoor in PCP, if I had to?

As it turned out the answer is hillariously simple! PCP, as GNUPG, supports encrypting data for multiple recipients. Therefore the task is easy: create a "government key pair", hardcode its public key into the encryption code and encrypt everything for this recipient as well.

Here's the backdoor patch.

The patch includes the "government's" secret key. Here's how to use it:

1. Compile the patched pcp source as usual, install the binary as pcp1-backdoored or something like that.
2. Create a test user on your system, say "spook".
3. As user "spook" import said secret key, the import passphrase is "gov".
4. As another user on the same system export your public key.
5. Import that key as user "spook".
6. Now as the regular user, encrypt some file asymmetrically for someone else (e.g. import one of the public key files in the tests/ directory of the source code) using the backdoored binary.
7. As user "spook" decrypt the encrypted file as if you'd be the intended recipient.
8. Et voilá.

Demo:

[24.Aug 17:09:05] --- [~] ---
tom@vm: % src/pcp1 -V spiedsender.vault -l
Key ID               Type             Creation Time        Owner
0x5C77C305F0BF8333   primary secret   2016-08-24T15:13:02  Freddy Victim <victim@gmail.foo>
0x616BDDA58845987B   valid public     2015-04-17T17:08:19  Bobby <bobby@local>
[24.Aug 17:15:29] — [~] —
tom@vm: % src/pcp1 -V backdoor.vault -l
Key ID               Type             Creation Time        Owner
0xF93E7016447D28CC   primary secret   2016-08-24T14:54:28  The Government <spooks@the.gov>
0x5C77C305F0BF8333   valid public     2016-08-24T15:13:02  Freddy Victim <victim@gmail.foo>
[24.Aug 17:15:43] — [~] —
tom@vm: % echo “for bobbys eyes only” | src/pcp1 -V spiedsender.vault -i 0x616BDDA58845987B -e -O encrypted-for-bobby.asc
Enter passphrase to decrypt your secret key:
Encrypted 242 bytes for:
0x616BDDA58845987B - Bobby <bobby@local>
[24.Aug 17:16:14] — [~] —
tom@vm: % src/pcp1 -V backdoor.vault -I encrypted-for-bobby.asc -d
Enter passphrase to decrypt your secret key:
for bobbys eyes only
Decrypted 21 bytes successfully

There you go. Freddy Victim encrypted some message for Bobby, but the "government" could read it anyway, it only had to import Bobby's public key (which is the difference to PGP, but it's public and much easier to retrieve).

Also note that the "government" just uses regular PCP features, it doesn't even need to use a patched binary, the vanilla one would do. That's because the backdoor is not really a cryptographic backdoor (which is, as many cryptographers already said, impossible). Instead it just adds another recipient. The result looks pretty normal to the uninitiated, just some encrypted file decryptable by two recipients instead only one.

So, as you can see, it couldn't be easier to implement this backdoor. I could even commit this code to Github and I'm pretty sure, no one would take notice (and of course in that case I'd obfuscate it a little to disguise a casual reader). Also, the government could distribute the patched binary. That'd be pretty easy as well, since almost all Open Source systems use binary packaging.

Finally, one question remains though:

How could I determine of an encrypted file has a "hidden" recipient?

I'm not sure. In the case of PCP, I added a debug print statement to the decryption code (git commit) which tells the number of recipients during decryption if -v have been supplied on the command line. Maybe GPG already includes such a function. But of course this could be easily patched away by a backdoored version. So to check if an encrypted file contains more recipients than expected you'd need to check out the source code, compile it manually and then do the checks.

Yes, evil and scary stuff. But as the README of PCP says loud and clearly: Do not use PCP for anything productive or important. However, for real live public key crypto systems the scheme to add a government recipient to all encrypted data could be a realistic possiblity.