Page MenuHome GnuPG

Gpg4win: Error when parsing message (attempts to decrypt unencrypted public key block)
Closed, WontfixPublic

Description

Hi,
There are 2 symptoms to this issue:
Symptom 1: Unencrypted plaintext disappears
When the message/email is composed of a PGP message block + some plaintext, the plaintext is not shown in the output.

Symptom 2: Unencrypted public key gives an error
When the message/email is composed of a PGP message block + a PGP public key block, an Unexpected error is raised.

Possible solution
I assume there is some kind of parsing mechanism choosing what to decrypt.
The parsing mechanism could be more restrictive in order to decrypt only the blocks containing the header -----BEGIN PGP MESSAGE----- and not the blocks containing the header
-----BEGIN PGP PUBLIC KEY BLOCK-----.
In addition, it could be handy to show in the output all plaintext that was not contained in the PGP message block (unless I am not seeing a possible security issue).

Why care about this?
Some third party encryption clients, like the FlowCrypt chrome extension, give the option to add an unencrypted footer or the sender's public key to the email.
The fact that the unencrypted footer disappears after decryption is not a big issue, but the decryption of the unencrypted public key block is more problematic:
When using the command line to decrypt, I get the decrypted message along with a "gpg: decrypt_message failed: Unexpected error".
However, when using Outlook with GPGOL, I cannot see any text. It only shows "Could not decrypt the data: General error".

I know that GPGTools on OSX already implements this functionality: everything that is not in a PGP message block is shown under the decrypted message. The email is then described as "Partly encrypted".

Thank you

Details

Version
2.2.1

Event Timeline

aheinecke triaged this task as Normal priority.
aheinecke added a subscriber: aheinecke.

Indeed the PGP Inline handling should be more robust. If there is leading of following text it should not error out. But as there will always be problems with that I really recommend that you use a standard format (PGP/MIME) to communicate. Then the key would be just an attachment that could be imported in Kleopatra and all the data would be encrypted / signed.

The problem with that mix is that we don't have a way in GpgOL that can't be faked by an HTML Mail to show if there might be some weird mix of encrypted / signed /unencrypted / unsigned mail.

There won't be improvements to PGP/Inline