protocol updates

This commit is contained in:
Rusty Striker 2024-12-06 16:44:31 +02:00
parent 2df8de0a3e
commit c26576f31f
Signed by: RustyStriker
GPG key ID: 9DBDBC7C48FC3C31

View file

@ -3,6 +3,29 @@
All encryptions are made using RSA (key size to be determined), no symmetric encryptions All encryptions are made using RSA (key size to be determined), no symmetric encryptions
are used due to messages being short. are used due to messages being short.
<!-- Maybe yse RSA-256 (or the closest)? if i can assume it is unbreakable that is -->
## Some problems
Do i need hasing? dont think it will help too much, can just sign-encrypt i think.
When asking for messages, maybe do a little back and forth with the server to make sure
the request comes from the correct person?
Maybe keep track of the last message ID every time? then add it to the request,
not good, as if there were no new messages an attacker can now use said req.
Maybe the current timestamp? then the server keeps track of the last request with
timestamp for a given user? kinda acts like a better counter i think.
I dont think someone can abuse this system.
I think adding this to every request is neccessary to make sure no duplicates are
being sent, ie. if an attacker listens on the channel and sees a package sent to
the server, it can repeat it and cause mischief (maybe send duplicate messages,
or flush the user's messages or something).
an attacker can also abuse duplicates to see who a user is talking to,
simply send the request and encrypt all public keys (gotten in a legitimate way)
using the user's public key (as the server would encrypt) and compare the result
from the server
## Registration: ## Registration:
- User sends a register request to server `(phone number, RSA public key)`, - User sends a register request to server `(phone number, RSA public key)`,
@ -27,3 +50,20 @@ request and ultimately signed by A and encrypted using the server's key.
The server will hold on to the message until B will send a `GetMessages` request The server will hold on to the message until B will send a `GetMessages` request
to the server. to the server.
## Requests:
legend:
- `E(t)` encrypt t
- `S(t)` sign t
- `ES(t)` signed and encrypted (in that order!)
- `HS(t)`/`HS t` hash and sign t
All requests are to be encrypted using the server's public key, have the sender phone
and have a timestamp on them, except when otherwise noted
1. `Register(public key)`, no timestamp
2. `HS RegisterConfirm(6-digit code)`
3. `GetMessages`
4. `GetUserKey(phone - user to get key for)`
5. `SendMessage(phone - receiver, ES({ message_id, message }))`
6. `SendMessageACK(phone - ack receiver, ES({ message_id[], ACK/NACK }))`