protocol updates
This commit is contained in:
parent
2df8de0a3e
commit
c26576f31f
1 changed files with 40 additions and 0 deletions
40
protocol.md
40
protocol.md
|
@ -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 }))`
|
||||||
|
|
Loading…
Reference in a new issue