1669654 - OpenPGP: key ownerpreferences for to which symmetric ciphers/hash functions/compression algorithms should be honored

Status: UNCONFIRMED

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[Matthias Kirchhart]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

OpenPGP keys allow their owner to specify preferences as to which symmetric ciphers/hash functions/compression algorithms should be used. In GnuPG, these can be seen by:

gpg --edit-key "THE KEY YOU WANT TO LOOK AT"
showpref

When encrypting a message to such a key, these settings should be honoured.

1. Alice: Create a Key-pair, set cipher settings such that TWOFISH is the preferred symmetric cipher.
2. Alice: Export the public key, send it to Bob.
3. Bob: Import Alice’s public key into Thunderbird.
4. Bob: send an encrypted message to Alice.

Actual results:

The message is encrypted using AES-256.

Expected results:

The message should have been encrypted using TWOFISH.

There is nothing wrong with AES-256 per se, it is a secure cipher. Yet, if Alice specifies that she wants messages encrypted using a different algorithm, this should be honoured by default; unless Bob uses super advanced options to override this.

Comment 1

[neal]

I disagree with this bug report. Let's say I encrypt a message to N recipients. What should my OpenPGP implementation do? It needs to find a symmetric algorithm that is acceptable to all recipients. What if the intersection of the preferences is the empty set? Then it has to fallback to the only MUST algorithm, which is currently specified, TripleDES. What if there are multiple algorithms that are acceptable but in a different order (Alice chooses <A, B>, Bob chooses <B, A>). How do we choose? This is surprisingly hard.

Marcus Brinkmann noted that this is buggy in GnuPG:

Fun fact: If you ask #GnuPG to encrypt to a recipient that prefers "AES256, AES192, AES, CAST5, 3DES" in that order, and to another recipient that prefers the reverse order "3DES, CAST5, AES, AES192, AES256", then GnuPG will use, wait for it: 3DES! Ba Dumm Tsss

I followed up with him privately and he elaborated:

[T]here were a couple of issues in that area.

First, the attacker can simply choose the selected algorithm by only
including the one that should be selected. Of course, 3DES is always
included, so the attacker can either force 3DES, or force a choice
between 3DES and one other algorithm common to all recipients.

Not necessarily an issue, if you limit the output related to a symmetric
key to something well below 32 GB for 64 bit blocks.

Second, the way GnuPG scores the algorithms to select the best one is
not sound. The function select_algo_from_prefs calculates the score by
adding the index of an algorithm in the preference list of each key. The
idea is that the lower the score, the more strongly preferred it is by
the keys on average. However, there is no check for uniqueness, so an
attacker can simply list the desired algorithm first, then fill in an
invalid algorithm number a hundred times, and then list all the strong
algorithms, thereby giving them a high (=bad) total score.

Third, in a tie GnuPG prefers the lower algorithm identifier, which is
the older algorithm, and probably the weakest (for compatibility
reason). Because GnuPG does not check for uniqueness of preference
values, and the total score is capped at 0xffff, and the length of
subpackets in OpenPGP is unlimited (up to 4GB), the attacker can always
force a tie should the second approach above not work, because somebody
tries to defend by giving a bad algorithm a high score.

Further:

• Encryption policy should be sender-enforced, because only the sender
  knows the confidentiality of the message. If the recipient can not
  receive any of the ciphers acceptable by the sender, the message should
  not be sent.

  There is precedence for this at least for signing even in OpenPGP
  (RFC4880): "If you are building an authentication system, the recipient
  may specify a preferred signing algorithm. However, the signer would be
  foolish to use a weak algorithm simply because the recipient requests it."

• Even GnuPG allows personal preference to override the key preferences.

• Compliance (i.e., FIPS) may require the use of certain algorithms, and
  forbids the use of certain other algorithms, which can conflict with or
  override recipient preferences.

In short simpler is better. And, since everyone supports AES and AES is strong, just using AES is a good policy.

Comment 2

[Matthias Kirchhart]

Dear neal,

thank you for your response and putting this much thought into it. You are right, this is much harder than I thought and I agree with your Marcus Brinkmann’s analysis. As far as I am concerned, this bug can be closed.

As for the future, one possible alternative could be the following:

Keys should have a list of supported, i.e., not preferred, ciphers. When encrypting a message to multiple keys, one can simply form the intersection of the supported ciphers. The ‘best’ cipher can then be chosen by comparing intersection of viable ciphers with the sender’s preference list.

I do not understand enough about the details of the OpenPGP standard to know if this would be conforming or not. But this way encryption policy would be sender enforced.