search

freedomofpress / securedrop-protocol

Research and proof of concept to develop the next SecureDrop with end to end encryption.
GNU Affero General Public License v3.0
47 stars 1 forks source link

Server might swap, replace, replay ciphertexts #31

Open lsd-cat opened 9 months ago

lsd-cat commented 9 months ago

As reported by @mmaker the tuples meaages_id -> (MEPK,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 (MEPK, ciphertext) when specifically requested a message_id obtained through the fetching protocol.

Related to https://github.com/freedomofpress/securedrop-poc/issues/30

More details will be added.

mmaker commented 9 months ago

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 commented 6 months ago

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 https://github.com/freedomofpress/securedrop-poc/issues/30#issuecomment-1890931212 and not probably warranting a key decision change in the protocol.