Page MenuHome GnuPG

GnuPG: Compliance mode status omitted when decrypting combined symmetric and asymmetric data
Closed, ResolvedPublic

Description

Hi,

The problem is that Kleopatra shows "decryption is not VS-NfD compliant" for compliant data. But this issue is easy to reproduce on the command line:

With the GnuPG VS-Desktop 3.1.23 Appimage:

aheinecke@hopper ~> gpg --quick-gen-key foo@bar.baz
About to create a key for:
    "foo@bar.baz"

Continue? (Y/n) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: revocation certificate stored as '/home/aheinecke/.gnupg-vsd/openpgp-revocs.d/7D50D434670374AFF08049708923D884CAEC298A.rev'
public and secret key created and signed.

pub   rsa3072 2022-08-02 [SC] [expires: 2024-08-01]
      7D50D434670374AFF08049708923D884CAEC298A
uid                      foo@bar.baz
sub   rsa3072 2022-08-02 [E]

aheinecke@hopper ~> echo foo | gpg -c -er foo@bar.baz | gpg --verbose --status-fd 1 -d          
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   3  signed:   2  trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: depth: 1  valid:   2  signed:   0  trust: 2-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2024-02-02
gpg: public key is ACFA3868ED7D2682
[GNUPG:] ENC_TO ACFA3868ED7D2682 1 0
gpg: using subkey ACFA3868ED7D2682 instead of primary key 8923D884CAEC298A
[GNUPG:] KEY_CONSIDERED 7D50D434670374AFF08049708923D884CAEC298A 0
[GNUPG:] KEY_CONSIDERED 7D50D434670374AFF08049708923D884CAEC298A 0
gpg: using pgp trust model
[GNUPG:] DECRYPTION_KEY 435736AB02AC9C6BD63C8E65ACFA3868ED7D2682 7D50D434670374AFF08049708923D884CAEC298A u
gpg: encrypted with 1 passphrase
gpg: using subkey ACFA3868ED7D2682 instead of primary key 8923D884CAEC298A
[GNUPG:] KEY_CONSIDERED 7D50D434670374AFF08049708923D884CAEC298A 0
gpg: encrypted with 3072-bit RSA key, ID ACFA3868ED7D2682, created 2022-08-02
      "foo@bar.baz"
[GNUPG:] BEGIN_DECRYPTION
gpg: AES256 encrypted data
[GNUPG:] DECRYPTION_INFO 2 9 0
gpg: original file name=''
[GNUPG:] PLAINTEXT 62 1659450300 
[GNUPG:] PLAINTEXT_LENGTH 4
foo
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] GOODMDC
[GNUPG:] END_DECRYPTION

Both "echo foo | gpg -er foo@bar.baz | gpg --verbose --status-fd 1 -d " and "echo foo | gpg -c | gpg --verbose --status-fd 1 -d" will correctly emit "[GNUPG:] DECRYPTION_COMPLIANCE_MODE 23"

Event Timeline

aheinecke created this task.

Oh, there appears to be a reason for that. In line 699 of mainproc.c:

/* Symmetric encryption and asymmetric encryption voids compliance.  */
   && (c->symkeys != !!c->pkenc_list )

So is this a Kleopatra issue that it allows this operation and shows it as VS-NfD compliant?

aheinecke renamed this task from GnuPG: Complaince mode status omitted when decrypting combined symmetric and asymmetric data to GnuPG: Compliance mode status omitted when decrypting combined symmetric and asymmetric data.Aug 2 2022, 4:41 PM

This also points out that the cipher algos and modes of the symmetric encrypted session key packets where never checked for compliance. We only checked the compliance of the bulk encryption cipher algo.

Fixed in 2.2 and master. Did a couple of manual tests using 2.2 on Linux. gpgsplit comes handy to add a couple more tag-3 packets (same algos or one patched to camellia for the negative test)

aheinecke moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Aug 15 2022, 2:02 PM
werner removed a project: Restricted Project.
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 5 2023, 1:51 PM