Is there a reason for the assumed ISIS video's OpenPGP encryption key ID being outside base-16?

Question

I was reading an article earlier today about Edward Snowden and ISIS. According to him they faked an encrypted message. He uses the fact that they have an encryption key outside of base-16 as his proof. He also points out that the date of encryption is days later than the message. Here is a link to the twitter post by him:

https://twitter.com/Snowden/status/691396009587556353

I have a couple of questions though. Is it possible in PGP to change the settings to allow an encryption key outside of base-16? Are there settings that will allow a key of any thing you like? Is there a way to delay encryption that would explain the date differences?

Answer 1

Is it possible in PGP to change the settings to allow an encryption key outside of base-16?

This is not defined by OpenPGP (although I indeed couldn't find any source defining a hexadecimal representation). I discussed a similar example in How is this OpenPGP key displaying in a non hexedecimal format?, where some characters have been garbled probably seeking for anonymity.

Are there settings that will allow a key of any thing you like?

First of all, what was printed in the video was only a key ID, not an actual key. Key IDs are abbreviated versions of the hashed key, because it would be a hassle to pass over large 4kbit RSA keys to others (it already is a hassle with key IDs and fingerprints, though).

To get back to your question: no, GnuPG does not know such an option. You can choose between short and long key IDs, and whether to prefix them with 0x to denote hexadecimal numbers using the --keyid-format parameter and the values short, 0xshort, long and 0xlong -- no option for anything non-hexadecimal.

It there a way to delay encryption that would explain the date differences?

This might happen when different computers are used for creating the key and performing operations with it, when those computers have different times set up (with other words, at least one of the computers has a very wrong clock setting).

You can easily enforce such combinations by changing the time of your computer, or using the faketime tool (when compiled with debug settings, GnuPG also knows a --faketime parameter).

---

Looking at the proposed message, passing it through pgpdump which prints the OpenPGP package headers, reveals some completely other key:

$ pgpdump
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v2
>  
> hQIMA9vC6Cu3Y8+AAQ/9GHzcyGJyXWR3vp3T9chiAOF/VkaBrZUlerKSSrH3O
> ual8yGt68kQP67AeZqu+mwN4qw+kouURJZp3deMfaEub42Umlzszhwdq6dL43
> E7h3OKL8RGngTchTNqHLZrVDBvaFSUCn9ihS1ua5LXqu3uiYi2oszfe3uFM
> Jsiu6YszAF+1nkqjqNS/FsKYwauZ/zPRUkJ+mFRs8uHYCgP9U6PdeFOBSpTXr+
> Frd6pd0YU1Gwyc84ldTwODSszmevaKICHNrbKHOcBlvBtpS9DZHciF88qYURB
> w3ggaCa847A28karOhdeBPSfchdRerOthtJG/LZ7wRthchtsOle/H9BAI
> ra4bex8sdjJUYEUl8nsXxsp8anAwoePW7JAjTXagyUYSSkaYh6Q6v8vmena5I
> qSEhAusCochQ/F5J9o+85jBQG4ththu50CMR29BchoV1pLRYh3ngsEG2mn8
> EMthdncJ+qNDwaG2TVu9Pynw5HYTAdeA1HiOxZ1quvU44SFgGSer27waa2
> L90m80bYquV66DA9/xT2y0xAX3SuWOSXsi+uqioAhdo+140Eth77CqXUEIrme
> idwx+FDv9KhBPsnT8HC/cMEUz+5beSULBOTDNTQt6YCarG50PngxkkdngssPS
> wJUBtKC7Fx3Tc1c1PSImv+WO3DTF9V41NquyvVA8DoDEMUOJKHLLS6DloFImLAE
> nglHZ/yMN+hEF+AKWOpGAg3Eyfpb3IC/waI4TOIfG71E0q+ich6w3DQZk00vP
> j52092IVKNf19h50LquL1Zulzn30erXBWNGan3NJ8802/jcgpudXD+DGWgIeP
> X3XL4denHyLPVzl6wtts7TwHHf2twaknaGhuROBWXz+rI/anSRy9Iqa7t1tng
> wQTubedN3tdFsOAy8hUvZSyJQ3NLpdNerttePaTQ5PzOoprTTq0d4bClthoT
> vaQlNTMlDehYAHscbe4D7bN2M2fnxUMQEthFYRZDUSMPCTyjHBTgX3DwEMAdY
> mkadYxczOKOKEL22CvSMa7aHAC5th1iHj+cF4jN1t4uLCinxOngsz+G+GqT
> meYOimS/g==
>  
> =UmHe
>  
> —--—-END PGP MESSAGE-----
Old: Public-Key Encrypted Session Key Packet(tag 1)(524 bytes)
    New version(3)
    Key ID - 0xDBC2E82BB763CF80
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA m^e mod n(4093 bits) - ...
        -> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02
Old: Reserved(tag 0)(until eof)

Disclaimer: I retrieved this query by searching for the very first characters hQIMA9vC6Cu3Y8 and found a pastebin document which seems to contain the message, but with messed up linebreaks and other problems -- it seems like a bad OCR scan. I didn't verify further, but at least it's correct enough to be parsed. If anybody further compared them -- feel free to leave a message.

Answer 2

Is it possible in PGP to change the settings to allow an encryption key outside of base-16? Are there settings that will allow a key of any thing you like?

No. That piece of output is shown in base 16 (hexadecimal) just because it's a good way to show binary data (in this case a hashsum).

In this case it's as if they had codified a message in morse code, and the output, in addition of dots and dashes, had commas and semicolons. The underlying "message" may have anything, but if you are showing it in morse (eg. for radio transmission) you wouldn't have commas.

It there a way to delay encryption that would explain the date differences?

It's not that the encryption is delayed, but that the message is encrypted 3 days before the encryption key was created.

As if there could be plausible explanation, they could have generated the key in one computer, then used it in a different one, with one of them (or both) with the date set wrong. Most probably though, they were two pieces recorded recently, with the dates set manually in the past, and nobody smart enough to notice that the generated dates were inconsistent.