Server might swap, replace, replay ciphertexts

[lsd-cat]

As reported by @mmaker the tuples meaages_id -> (ME_PK,ciphertext,mgdh) are not cryptographically bound together. The server might act honestly in running the fetching protocol, and then act dishonestly by serving a different (ME_PK, ciphertext) when specifically requested a message_id obtained through the fetching protocol.

Related to #30

More details will be added.

[mmaker]

An additional note I didn't put in the report: it's hard for anybody to see that ME_PK is different between polling and reading (it's Decisional Diffie Hellman again)

[lsd-cat]

Keeping this open, as it matters if we end up choosing X3DH or similar instead of just public-key encryption. In any case, I argue that the risks and exploitability are extremely low as explained in #30 (comment) and not probably warranting a key decision change in the protocol.