You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 server support at maximum MAX_MESSAGES, generally < 10000. See also #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 #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 #32. Do we want a PKI? Do we want to do some version of Key Transparency instead? External input could be really useful here.
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 #14.
Scalability limit
The server support at maximum
MAX_MESSAGES
, generally < 10000. See also #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 #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 #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 #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 #31.
Attacker can spam to MAX_MESSAGES and know the number of messages in the server
See #43.
Key type confusion
See #53.
The text was updated successfully, but these errors were encountered: