• 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
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.
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:
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.
Is the chat encrypted (i.e. has an avatar that is not )? 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.
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
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.