1663400 - Unable to decrypt PGP messages from Symantec Encryption Desktop

Status: RESOLVED FIXED

(Thunderbird :: Security, defect, P1)

Description

[Marcel Dopita]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

I'm migrating from Thunderbird 68.x with Enigmail addon to newer Thunderbird with integrated support for OpenPGP. It does work, however emails from clients with Symantec Encryption Desktop are not decrypted.

Actual results:

Emails are decrypted fine with Enigmail addon but not in any release of Thunderbird (Stable 78.2.1, Beta 81.0b2 or the latest Daily 82.0a1 (2020-09-06)).
I noticed this with emails from my coworker but I verified it with clean install of Symantec Encryption Desktop 10.4.2 MP3 (Build 1298).

By default messages are formated in "PGP Partitioned". These messages are not decrypted at all and full raw encrypted content (BEGIN PGP MESSAGE...) is visible. No error is logged in error console.

I tried switching to "PGP/MIME". In this case Thunderbird doesn't display any content and logs "rnp_op_verify_execute returned unexpected: 268435457". (This should match "RNP_ERROR_BAD_FORMAT")

Expected results:

It's not a regression as there was no support for PGP in Thunderbird but I would expect even messages from Symantec Encryption Desktop to work. It prevents me from upgrading past Thunderbird 68 with Enigmail as I need to access both old and new emails.

Comment 1

[Kai Engert [:KaiE:]]

Attachment: alice-bob-kuix-sample-keys.asc

Comment 2

[Kai Engert [:KaiE:]]

Marcel, I've attached two public keys, the secret key material is also publicly available, so sharing test messages is easily possible for analysis.

Could you please import them, and send an encrypted test message to [e-mail] or [e-mail] ?

Thanks

Comment 3

[Marcel Dopita]

Thanks for prompt response. I have just sent two emails (with both partitioned and pgp mime formats) to bob-test.

Comment 4

[Kai Engert [:KaiE:]]

[init_packet_sequence() /home/user/github/rnp/src/librepgp/stream-parse.cpp:2208] unexpected pkt 10

From https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-09

5.9. Marker Packet (Obsolete Literal Packet) (Tag 10)

   An experimental version of PGP used this packet as the Literal
   packet, but no released version of PGP generated Literal packets with
   this tag.  With PGP 5, this packet has been reassigned and is
   reserved for use as the Marker packet.

   The body of this packet consists of:

   *  The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).

   Such a packet MUST be ignored when received.  It may be placed at the
   beginning of a message that uses features not available in PGP
   version 2.6 in order to cause that version to report that newer
   software is necessary to process the message.

Comment 5

[Kai Engert [:KaiE:]]

Nickolay, it sounds like this packet should be ignored, but the code in init_packet_sequence treats it with a failure RNP_ERROR_BAD_FORMAT.

Comment 6

[Kai Engert [:KaiE:]]

I'll attach three example message blocks.

Marcel, why does the first email contain two separate encrypted message blocks?
Is this the partitioning format you've mentioned?
Where is that documented?

Nickolay, after packet 10 is skipped, we should check if the attached messages can be processed, or if there are other problems.

You may find the secret key material here:
https://gitlab.com/openpgp-wg/openpgp-samples

Comment 7

[Kai Engert [:KaiE:]]

Attachment: s1p1.txt

Comment 8

[Kai Engert [:KaiE:]]

Attachment: s1p2.txt

Comment 9

[Kai Engert [:KaiE:]]

Attachment: s2p1.txt

Comment 10

[Marcel Dopita]

Marcel, why does the first email contain two separate encrypted message blocks?
Is this the partitioning format you've mentioned?

I believe these are plaintext and html parts of multipart message (the default "PGP Partitioned" format). I didn't configure (force) anything else and this is just a result of default behavior of MS Outlook 2019 and Symantec Encryption Desktop.

Comment 11

[Nickolay Olshevsky]

Thanks for reporting, absolutely forgot about this packet. And it's quite strange that implementations still issue it.
Created ticket at the RNP repository: https://github.com/rnpgp/rnp/issues/1296

Comment 12

[Kai Engert [:KaiE:]]

Marcel, could you please send me the signing key for testing? If you don't want to attach it, please send it by personal email to me. (I need it to look at the signature verification, too.)

Comment 13

[Kai Engert [:KaiE:]]

A newer RNP snapshot can decrypt the second test message. And it can decrypt the first part of the first message. We don't decrypt the second part of the first message, but I think that's deliberate.

Comment 14

[Marcel Dopita]

Great progress! I'm able to read emails from Symantec Encryption Desktop with latest Daily (82.0a1 3030-09-15). I only have issues with displaying non ASCII (Czech) characters (even though charset is in these emails set to UTF-8 and it works fine in Enigmail) - but that's for separate issue.

Comment 15

[Kai Engert [:KaiE:]]

Thanks for the feedback.
fixed by bug 1664885

Comment 16

[adnan]

Hi,

I have this same issue with the latest beta version (83.0b3) on Ubuntu 20.04.
Debug console is reporting: rnp_op_verify_execute returned unexpected: 268435457

Email encrypted using Symantec Encryption Desktop - 10.4.1 (Build 490).

Please let me know if I can help debugging this.

Thanks,
Adnan

Comment 17

[Kai Engert [:KaiE:]]

Adnan, because this older issue was fixed, what you experience is most likely caused by something else.
I suggest to file a new bug and send a test message as described above.
Thanks