This is a copy of my original post on Kudelski Security’s Research Blog for my archives.

I recently discovered a problem that involves PGP and a symmetric cipher called Camellia. It is possible to advertise the use of Camellia in your PGP public keys through the "cipher preferences", but if you do so, be aware that the official PGP software won't currently allow your correspondent to encrypt mails or files for you. Let's look at the details behind this observation.

Background

PGP (Pretty Good Privacy) is the main way to send encrypted emails nowadays. PGP has its very own standard for email encryption called OpenPGP and there are multiple OpenPGP solutions out there. Linux users generally rely on the free, open source software GnuPG, since it ships with most distributions. Corporate Windows users generally use commercial software instead and get professional support from the vendor. The most common PGP solution vendor is Symantec, which acquired the PGP Corporation in 2010, (see Wikipedia for a short history of PGP). It currently distributes and supports an OpenPGP-compliant software, originally called PGP Desktop, now known as Symantec Encryption Desktop. At the time of writing, I tried this all on Symantec Encryption Desktop version 10.4.1.

In the rest of this article, "PGP" refers to the OpenPGP standard description – not the software nor the company.

Encrypting with PGP

Since PGP allows you to easily encrypt data you intend to send to a given set of recipients, it naturally ends up using asymmetric cryptography.

Asymmetric cryptography is well suited for that task since it allows you to have a key pair (Kpublic ; Ksecret), with one public component Kpublic that anybody can use (typically to encrypt data for you, or verify data signed by you); and one secret component Ksecret that allows you to decrypt the data encrypted for its public counterpart or to sign data. This is different to symmetric cryptography, which would require you to have a common, shared key in order to both encrypt and decrypt data.

Now, what you actually want to do is to encrypt, send and decrypt the data efficiently, which is sadly not the main feature of asymmetric schemes. So you can obviously try to encrypt 4Mb of data for 10 recipients using only asymmetric cryptography, like the RSA cryptosystem, but then you'll have the same data contained in 10 different ciphertexts. You would end up with around 40Mb of data to send by email, since each ciphertext is specifically made to be decrypted only by one private key and contains all the plaintext information. This clearly reduces the desirability factor of asymmetric schemes.

When we do asymmetric encryption nowadays, we actually use an hybrid cryptosystem, which encrypts the data with an efficient symmetric algorithm such as AES-256, and only encrypts the AES Data Encryption Key (DEK) of 256 bits using the multiple recipients public keys. This means that we end up with a very small overhead of typically less than 24Kb, way better than what I described in the previous paragraph.

So, what symmetric algorithm should we use when we send an email using PGP? The asymmetric algorithm is already defined by the key type: it's typically RSA encryption, but there are multiple possibilities regarding the symmetric scheme used.

In fact, it's worth pointing out that the PGP public keys also contain the symmetric algorithm preferences of its owner, listing the symmetric schemes one would like to use!

Public Keys

Since PGP is based on an hybrid encryption scheme, each user generates (securely) her key pair first. They then reveal (thanks, for example, to a key server) their public key.

You may not know this, but when you export your public key, you are actually exporting multiple PGP packets at once. Usually a simple public key (e.g. created with the default gpg --gen-key settings) is constituted of:

However you might have more than just those five packets in a key, since it is possible to have subkeys. Each of those would then have its very own signature packet certifying its purpose and binding it with the primary key. Those packets are typically visible if you try to do a gpg --list-packet key.asc or a pgpdump < key.asc. Amongst the data contained in the signature packets, there is a field called "Symmetric Algorithm Preferences", which is simply a list of the symmetric algorithms accepted by the key-holder. You can typically have a human readable list thanks to the command gpg --edit-key nameofyourkey showpref, like (and these aren't the default) e.g.:

Cipher: AES256, AES, CAMELLIA256, 3DES
Digest: SHA512, SHA256, SHA1

Finally, since OpenPGP has a must-have algorithm and a must-have digest, namely TripleDES and SHA-1 (!), even if they are not listed in the preferences fields, these are tacitly appended at the end of the preference list.

This latest detail is important since it ensures you can always fall back to a common cipher, TripleDES, when using PGP. Thus, you'll never have to completely give up on security, even if your interlocutor is only advertising ciphers you cannot use in their preferences' list.

PGP preference hiccup

If you are like me and you find that Camellia is still a cool cipher (no, not just because of its name!), then you might have added it as one of your preferred ciphers in your PGP key... After all, it has been added to OpenPGP through RFC 5581 and to GnuPG starting with v1.4.10 since 2009!

In case you're wondering, Camellia is a symmetric cipher designed in Japan as an alternative to AES. It is approved by ISO, the NESSIE project and the Japanese CRYPTREC project and can even be used in TLS.

Well, if you have, let me warn you: users of the Symantec Desktop Encryption tool (i.e. the official PGP client) are presently unable to send you any encrypted data using your public key as it is. It will error out when encountering such an unknown cipher in the preferred list instead of kindly using one of the other ciphers listed in there, (or in a worst case scanario, fall back to TripleDES, as it should always be able to).

The error in question as shown in the logs The error in question as shown in the logs! ("cipher number", but "CypherAttachments", sic)

What does this mean in the end? Well, two things in my opinion:

  • The standard does not define sufficiently well how those preferences should be handled. If you advertise Camellia, or other less common ciphers in your PGP public key, you are at risks of disappointing some people since they won't be able to use PGP correctly with your public key and their PGP implementation, even if both of you should in theory support TripleDES, or you also advertise AES in your key (which is almost omnipresent nowadays).
  • PGP clients should try to truly comply with the OpenPGP standard, which specifies that:

    “[...] if an implementation chooses not to implement some of the preferences, it is required to behave in a polite manner to respect the wishes of those users who do implement these preferences.”

    And I do not consider erroring out upon encountering an unknown cipher in that list something polite. Actually that's even rude since we both support TripleDES.

In the end, I've responsibly opened a ticket on Symantec's support to disclose this bug, and it appears that this is not a bug but a "feature request" (sic!). So be it. Maybe Camellia and other "unknown ciphers" will not prevent people to use another common algorithm soon!