We should update the section of the README 'Limitations and Discussion' to map the known potential problems in the protocols that are mostly there to stay ('Limitations') and an 'Open Problems' section mapping the issues we are currently try to figure out and the associated discussions and resources so far. Improving the clarity of the section will help us assess the state of the protocol, and external people to find out where there is room for contribution. I am also adding a 'Product Questions' section to map the missing specifications in the protocol that we have not decided yet.
The protocol does not implement flood protections, an attacker can disrupt the server by sending MAX_MESSAGES.
Open Problems
Attachments
Attachments are currently in a draft state and have not been audited.
Post-quantum security
We are fine in not having PQ security for the message fetching mechanism (3 parties DH) as there is no straightforward PQ primitive to use (see https://github.com/freedomofpress/securedrop-protocol/issues/48). We still want PQ security on message encryption and we have to decide which KEM and library to use and how that fits into the current protocol.
Traffic analysis
While we want to reduce the trust in the server by not having users and having all messages look the same. The server can still see request patterns and obtain information from that. Can we protect against traffic analysis in any way? Should we look at Signal like solutions (enclaves)? Can any type of decoy traffic help? We need an external assessment and suggestions.
Premise
We should update the section of the README 'Limitations and Discussion' to map the known potential problems in the protocols that are mostly there to stay ('Limitations') and an 'Open Problems' section mapping the issues we are currently try to figure out and the associated discussions and resources so far. Improving the clarity of the section will help us assess the state of the protocol, and external people to find out where there is room for contribution. I am also adding a 'Product Questions' section to map the missing specifications in the protocol that we have not decided yet.
Limitations
Covert communication
See https://github.com/freedomofpress/securedrop-protocol/issues/14.
Scalability limit
The server support at maximum
MAX_MESSAGES, generally < 10000. See also https://github.com/freedomofpress/securedrop-protocol/issues/49.Denial of service
The protocol does not implement flood protections, an attacker can disrupt the server by sending
MAX_MESSAGES.Open Problems
Attachments
Attachments are currently in a draft state and have not been audited.
Post-quantum security
We are fine in not having PQ security for the message fetching mechanism (3 parties DH) as there is no straightforward PQ primitive to use (see https://github.com/freedomofpress/securedrop-protocol/issues/48). We still want PQ security on message encryption and we have to decide which KEM and library to use and how that fits into the current protocol.
Traffic analysis
While we want to reduce the trust in the server by not having users and having all messages look the same. The server can still see request patterns and obtain information from that. Can we protect against traffic analysis in any way? Should we look at Signal like solutions (enclaves)? Can any type of decoy traffic help? We need an external assessment and suggestions.
PKI/Key authentication
See https://github.com/freedomofpress/securedrop-protocol/issues/32. Do we want a PKI? Do we want to do some version of Key Transparency instead? External input could be really useful here.
Product Questions
Message authenticity/deniability
See https://github.com/freedomofpress/securedrop-protocol/issues/30.
Message deletion
Do messages self expiry or do users delete them?
Security bugs in the PoC
Server can replay, mix ciphertexts and clues
See https://github.com/freedomofpress/securedrop-protocol/issues/31.
Attacker can spam to MAX_MESSAGES and know the number of messages in the server
See https://github.com/freedomofpress/securedrop-protocol/issues/43.
Key type confusion
See https://github.com/freedomofpress/securedrop-protocol/issues/53.