A centralized messaging system that should impart as little information as possible to any third parties, including the server administrator. Any information accessible by the server administrator is considered public as far as user security is concerned.
The server should be practical and attempt to disencourage unwanted behaviour like spamming. It should also have access control to allow private servers, but not at the cost of revealing message senders.
F(x) | x encrypted with F
P | inbox owner's public key
P' | inbox owner's private key
Q | message sender's public key
Q' | message sender's private key
S | server's public key
S' | server's private key
userid | 8 first characters of the user's public key encoded in base64
msgid | SHA-256 hash of the P(Q'(msgdata))
s-msgid | P'(msgid)
metadata | JSON object with properties "sender" (String, public key of message sender)
and "timestamp" (String, ISO-8601 datetime)
msgdata | message data content
e-metadata | P(metadata)
es-msgdata | P(Q'(msgdata))
postdata | <e-metadata length in bytes as ascii integer> '\n' <e-metadata> <es-msgdata>
s-postdata | S(postdata)
GET /serverkeys.txt
Description | gets server key file
Returns | server key file
GET /user/<userid>
Description | gets user inbox listing
Returns | [String] containing each msgid in users inbox
POST /user/<userid>
Description | posts to user inbox
Data | s-postdata
GET /user/<userid>/<msgid>.meta
Description | gets message metadata file
Returns | e-metadata
GET /user/<userid>/<msgid>
Description | gets message file
Returns | es-msgdata
DELETE /user/<userid>/<s-msgid>
Description | deletes a message
Consists of two parts, separated by two consecutive newlines.
First part consists of one row for each user. Each row contains the user's userid and the server's public key encrypted with the user's public key.
The second part contains the server's public key encrypted with itself for verifying that each encrypted public key is the same.
- Easy replication for secondary read servers to hide message read events
- Message sender remains hidden to the server, but access control is still enforced
- Server key file can't offer separate keys for each user in an attempt to identify senders because of the S(S) at the end
- Users can discuss the server's security on the server without the server adminstration knowing about it (useful when a user notices the server key file not being consistent to warn others)
- Users can verify their messages have arrived to the recipient's inbox unchanged
- Message senders and timestamps are verified with signing
- Server public key can be changed at intervals to limit spam effects of it leaking
- Message arrival times per user are public
- Message frequencies per user are public
- Userids can be associated to network addresses/people if no other means of anonymization (eg. Tor) is used
- User may be vulnerable during initial public key insertion depending on method
- Everything is wide open for brute force attacks
- Anonymous inboxes: After being accepted into the server, a user may send a signed-for-server request for an inbox along with an inbox key. This inbox key is used to validate incoming messages as belonging to this particular inbox. Since the inbox and message key holder are separate, the server maintainer has no way to connect inboxes to users.