No perfect forward security. It's a feature, not a bug.

It doesn’t feel like a feature to me. And neither does the lack of deniability. They both feel like things that leak information that doesn’t need to be leaked.

Perfect forward secrecy requires two-way real-time communication, in order to construct a session key that can't be computed from just the private keys and the encrypted message. Therefore the way that PGP's lack of perfect forward secrecy is a feature is that it allows an encrypted message to be generated in a way that doesn't require two-way real-time communication, and can therefore be sent by email.

The trade-off is that you then don't have perfect forward secrecy.

Why does signal still work when the other party is offline?

Seems somewhat like threat model will determine the need for deniability etc. I don't consider myself to need it, and mine seems like a common enough case - compatible with a normal WhatsApp user's use case.

whatsapp and signal have forward secrecy, so if your private key is leaked it means that past conversations can't be decrypted. In reality it does not offer a lot of protection if you don't disable keeping logs (because losing your phone and malware are the only realistic ways of your private key being leaked). In addition the way that they have forward secrecy implemented it means that you have to decrypt every message posted in groupchats while you were offline sequently until the last one, which can take hours in an active (even if small) group if you are gone for a week. The other thing is that both of these apps to my knowledge do not warn you if a new key is added (I might be wrong here) so an active attacker can pretty much nullify the encryption, this is not an issue with openpgp.

To add to this: the point of the disappearing messages in signal is to enhance the value of the forward secrecy by not having the record of the messages (so long as both devices are using correct clients and no one is screenshotting messages.

The other feature is deniability: having an encrypted message and it’s decryption doesn’t give you any more information than a screenshot of the message in signal. There isn’t a way for the encrypted message to prove that it was legitimate as the previous keys are revealed in a way that means anyone sniffing the traffic could make a message encrypted with that key.

Afaik, the messages should be deniable as long as they are not signed, not sure how delta chat handles it though. Regarding deniability I personally would consider it as an anti-feature because the one receiving the message can't prove to the wider world that they received it from a certain person and similarly someone who is falsely accused of posting a certain message can't go and say "show the signatures of the messages or you are lying".

By the way, do you know if the one receiving the messages can force messages that are marked as "disappearing" to be kept?

It is true that messages would be deniable if they weren’t authenticated. The design of signal’s protocol is such that messages are authenticated but deniable: it is possible for the recipient to determine that the message was genuine (the information you want to send) but it is not possible for a third party to prove that a message was authentic (the information you don’t want to leak).

See also, this article about doing the same for email: https://blog.cryptographyengineering.com/2020/11/16/ok-googl...

> The design of signal’s protocol is such that messages are authenticated but deniable: it is possible for the recipient to determine that the message was genuine

Via the use of MACs, yes. I never said otherwise. What I said before still holds, as the recipient you can't prove to others that you indeed received a message by a certain someone rather than forged it yourself to incriminate them.

> See also, this article about doing the same for email: https://blog.cryptographyengineering.com/2020/11/16/ok-googl...

The "Marisa" person in the comments is a friend of mine from IRC and I agree 100% with what she said.