Can't decrypt some messages sent from other app

[This message cannot be decrypted.

• It might already help to simply reply to this message and ask the sender to send the message again.

• If you just re-installed Delta Chat then it is best if you re-setup Delta Chat now and choose Add as second device or import a backup.]

I got that on the new version that was just pushed out to Android on a normal PGP (not Autocrypt) email. The older messages in the name thread have gotten through just fine and my other MUA can decrypt the new one because nothing changed on the sender’s end,only change is that Delta Chat upgraded.

Decryption in Delta Chat does not depend Autocrypt. Without Autocrypt header we may be unable to check the signature, but missing Autocrypt should not result in decryption failure. I have also looked, there are no recent changes in how we handle decryption. We load all the keys that you have (it is possible to have multiple keys if you previously imported more keys in older versions which had this option) and try to decrypt each incoming message with all of them.

There may have been changes in rPGP library that we use for decryption. For example, it no longer decrypts insecure Symmetrically Encrypted Data packets which are not authenticated: GitHub · Where software is built

Is the problem reproducible? Do you know which email client was used to send the message?

If you have access to the .eml file and can check its packet structure with e.g. gpg --list-packets tool, it can be helpful. As a last resort you can send a copy of encrypted payload to me or to delta@merlinux.eu

He uses Gnus v5.13 according to the headers. Decrypting from him in Delta Chat worked just a few hours earlier.

Here’s list-packets output (5862 is me):

gpg: encrypted with ? key, ID F0161C9E4E83C87A
gpg: public key decryption failed: Invalid public key algorithm
gpg: encrypted with 255-bit ECDH key, ID 4E7ABC5EC44E5862, created 2023-11-24
      "Sandra Snan <sandra.snan@idiomdrottning.org>"
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 4E7ABC5EC44E5862
	data: [263 bits]
	data: [392 bits]
# off=96 ctb=85 tag=1 hlen=3 plen=1178
:pubkey enc packet: version 3, algo 8, keyid F0161C9E4E83C87A
	unsupported algorithm 8
# off=1277 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
	length: unknown
	mdc_method: 2
# off=1298 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=2
# off=1300 ctb=90 tag=4 hlen=2 plen=13
:onepass_sig packet: keyid 3C195615A4EA45D6
	version 3, sigclass 0x01, digest 10, pubkey 22, last=1
# off=1315 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb
:literal data packet:
	mode t (74), created 1755276015, name="epg-input97vATz",
	raw data: unknown length

And here is one from the same thread that Delta Chat could decrypt:

gpg: encrypted with ? key, ID F0161C9E4E83C87A
gpg: public key decryption failed: Invalid public key algorithm
gpg: encrypted with 255-bit ECDH key, ID 4E7ABC5EC44E5862, created 2023-11-24
      "Sandra Snan <sandra.snan@idiomdrottning.org>"
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 4E7ABC5EC44E5862
	data: [263 bits]
	data: [392 bits]
# off=96 ctb=85 tag=1 hlen=3 plen=1178
:pubkey enc packet: version 3, algo 8, keyid F0161C9E4E83C87A
	unsupported algorithm 8
# off=1277 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
	length: unknown
	mdc_method: 2
# off=1298 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=2
# off=1300 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb
:literal data packet:
	mode t (74), created 1755202594, name="",
	raw data: unknown length

rPGP 0.16.0 has been used since core version 1.160.0 released on 2025-06-22.
According to iOS changelog core 1.160.0 was not used in the releases, app updated from 1.159.5 to 2.8.0. So it is likely a problem in rPGP.

PKESK algorithm 8 looks strange, apparently it is a non-standard algorithm “Kyber” from draft-koch-librepgp-03 - LibrePGP Message Format
This is likely a packet for the sender so should be skipped, but maybe it causes problems with the new rPGP 0.16.0.
There is a related bugfix in rPGP that was made after 0.16.0 and is not released yet:
fix: handle parsing of unknown PKESK packets (#568) · rpgp/rpgp@09a6b1e · GitHub

I have tried to reproduce the bug by manually changing algorithm to 8 in a test message for one of the unused PKESK packets, and still managed to decrypt it with rPGP 0.16.0 using rsop:

$ rsop version --extended
rpgpie-sop 0.7.2
sop-rs 0.8.2
rpgpie 0.6.4
rpgp 0.16.0
- bzip2: yes

So maybe the problem is not this “algorithm 8”.

The other suspicious thing is that the failing message has a “text signature” (class 0x01), while successfully decrypted message is not signed. Delta Chat normally generates binary signatures (class 0x00). Not sure if there could be a problem, also worst case the signature validation should fail but the message should be displayed.

Compression algorithm 2 is zlib, nothing special here, it is supported.

I forgot to say that I switched to Android :woman_shrugging:t2:

Also not sure why I can’t reply to these posts from Delta Chat :thinking:

To dlarify, I switched to Android early June. And then it was this latest Delta Chat update that could no longel decrypt.

Is the chat encrypted (i.e. has an avatar that is not :envelope:)? Is there an error when you try to send the message?

It seems like your contact added non-standard Kyber encryption key. This is a GnuPG-only extension (so-called “LibrePGP”) and is not supported in rPGP. If there is only such encryption key available for the contact, then we cannot encrypt the message.

The easiest fix to all these problems is likely for your contact to stop using non-standard keys. But nevertheless, we should be able to decrypt messages sent to us, this is a bug that Delta Chat needs to fix in any case.

By “reply to these messages” I meant the ones you’re sending here. It says Visit Topic or reply to this email to respond. But there’s no reply box.

Discourse sends notifications with a List-ID header but without List-Post, so it appears as a read-only mailing list.

We can try to reproduce the bug if you also ask which particular version of GnuPG and operating system is used and whether Kyber encryption subkey was generated on purpose or offered by GnuPG by default. At least GnuPG versions shipped in Debian and Arch Linux currently don’t even allow to create such non-standard keys and specifically patch this (anti-)feature out.

Okay, I apologize :woman_bowing:t2::woman_bowing:t2::woman_bowing:t2::woman_bowing:t2:
The guy actually did switch to Kyber in between two messages 18 hours apart just when Delta Chat happened to update. Thank you for your help and patience with tracking this down.

1 Like