client: check msg_id for replay attacks

[ernado]

The client must check that msg_id has even parity for messages from client to server, and odd parity for messages from server to client. (1)

In addition, the identifiers (msg_id) of the last N messages received from the other side must be stored, and if a message comes in with an msg_id lower than all or equal to any of the stored values, that message is to be ignored. Otherwise, the new message msg_id is added to the set, and, if the number of stored msg_id values is greater than N, the oldest (i. e. the lowest) is discarded. (2)

In addition, msg_id values that belong over 30 seconds in the future or over 300 seconds in the past are to be ignored (recall that msg_id approximately equals unixtime * 2^32). This is especially important for the server. The client would also find this useful (to protect from a replay attack), but only if it is certain of its time (for example, if its time has been synchronized with that of the server). (3)

We've already implemented (3) and (1), this issue tracks implementation of (2)

Epic: #155

[Lakbaypanahon]

mychoiceback@icloud.com

…

On Feb 19, 2021, at 12:45 AM, Aleksandr Razumov ***@***.***> wrote:  The client must check that msg_id has even parity for messages from client to server, and odd parity for messages from server to client. (1) In addition, the identifiers (msg_id) of the last N messages received from the other side must be stored, and if a message comes in with an msg_id lower than all or equal to any of the stored values, that message is to be ignored. Otherwise, the new message msg_id is added to the set, and, if the number of stored msg_id values is greater than N, the oldest (i. e. the lowest) is discarded. (2) In addition, msg_id values that belong over 30 seconds in the future or over 300 seconds in the past are to be ignored (recall that msg_id approximately equals unixtime * 2^32). This is especially important for the server. The client would also find this useful (to protect from a replay attack), but only if it is certain of its time (for example, if its time has been synchronized with that of the server). (3) We've already implemented (3) and (1), this issue tracks implementation of (2) Epic: #155 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.