Prevent replay attacks

[npip99]

Feature Description

Example Proposal (Though there could be other ways of doing this):

• Note that the server already verifies signatures before anything else. So, the server will only accept signed packets before it reads the packets' contents.
• The client should label every packet with a unique ID starting at 1, where the client increments the ID for each packet that it sends.
  • This will have to be synchronized between TCP and UDP somehow, since a MITM could replay between the two protocols. Perhaps this should happen at a higher level?
• The server, should only be willing to receive the ith packet at most once
  • E.g. Using an all-initialized-to-negative-one integer ringbuffer that remembers the received IDs of the last 10,000 packets. It drops packets with IDs <= the value in the ringbuffer, and accepts and overwrites the ringbuffer with newer IDs when they're received
• The server, should presume the client is using SHA256("client", private_key) as its private_key, so that the server can't be replayed its own packets. (Re: @wangyu-)

This resolves any possible attack created by replaying packets sniffed by an attacker, either by feeding the server packets previously signed by the client, or feeding the server packets previously signed by the server. Since the attacker can't sign packets, these two situations are the only possible replay attacks available to the attacker.

~~

The same algorithm should be used in the reverse direction, so the client can't be replayed signed packets either, since that could also disturb the stream.

~~

NOTICE OF LOW PRIORITY

We do not currently wish to support protecting clients who are communicating over unencrypted channels and who have malicious actors physically near them or their network, trying to packet sniff / MITM / DNS poison that particular individual.

MITM fundamentally DOS's that user anyway, even for non-Whist users, as SEQ number attacks can trivially be used to shutdown TCP access entirely. Even TLS/SSL doesn't resolve this.

So, this GH issue is strongly low-priority.

Replay attacks can currently do weird things like cause the user to type things they didn't mean to type, or resend clipboard events, or DDOS, or intercept the handshake, or even force a disconnect or total loss of communication. These are known issues. Note however that it fundamentally does not allow a packet sniffer to decrypt a packet, since we do not send the private key over the network. Recall also that we generate a random IV for every packet, so a packet sniffer additionally cannot engage in frequency analysis to figure out which keyboard packets refer to what letter for example.

[npip99]

Re #5114, this GH issue it open to address replay attacks entirely, not just some subset of replay attacks.

[wangyu-]

See also the comment in #4785.

[npip99]

Moving a comment from Yancey over here:

~ We may want to consider using a different key for client and server, potentially using hkdf based off of SHA256, to address the situation where a computer running Whist is fed its own packet.

The description has an additional bullet point now to address this issue.