Implement session rekeying

[ovalseven8]

Link to the complete history of the issue: irungentoo#1254

Most important/informative quotes:

@irungentoo wrote:

Do you create a random public/private keypair per session, or do you directly create per session symmetric keys?

The answer is both. It creates a session keypair with NaCl and sends it to the other peer, the other peer then uses that public key and their session secret key to generate a shared key used for symmetric encryption. (You do the same thing with their session public key and your session secret key and get the same key). That key is then used to encrypt everything sent via the connection.

Please rekey after a given time! Let's say after 2 hours or 500 text messages or 10MB of transferred data, depending on which happens first.

Yes, that's planned. How does rekeying every 2^16 packets sound? Personally I think that rekeying isn't that needed because if someone gets access to your machines ram while you are running Tox they can get all your messages from the message log of whatever client you are running. If someone has enough access to your system to obtain the session key then they don't even need it to know what you were doing with Tox.

But since it's not hard to implement and doesn't have any drawbacks I have no issues with implementing it.

@codedust wrote:

The point is to make it even more difficult for an attacker (with a lot of computing power) who has no access to your machine to decrypt your whole communication during one session. Note that sessions can get quite long on mobile devices.

Anyone interested in this may read these two blog post from OWS explaining how (and why) they designed the protocol behind Textsecure:
https://whispersystems.org/blog/asynchronous-security/
https://whispersystems.org/blog/advanced-ratcheting/

[SkyzohKey]

This is related to #210, we currently would need a threat model before thinking about fixing issues that may never happens.

ie. Let's assume that user computer is safe (you can't do anything against that) but bootstrap nodes can be compromized, or an attacker (Eve) can steal your friend's tox save file and impersonate it. This should be made impossible by using Forward secrecy, Ratchets systems and Future secrecy.

The main idea is to not encrypt everything with the same key, but with derrivated keys, to ensure that if a key is compromized it won't affect the entire past conversation nor the one that could takes place.

[GrayHatter]

ie. Let's assume that user computer is safe (you can't do anything against that) but bootstrap nodes can be compromized, or an attacker (Eve) can steal your friend's tox save file and impersonate it. This should be made impossible by using Forward secrecy, Ratchets systems and Future secrecy.

If someone steals your keyfile, there's nothing toxcore can do about that. A ratchet system won't protect you from that.

The main idea is to not encrypt everything with the same key, but with derrivated keys, to ensure that if a key is compromized it won't affect the entire past conversation nor the one that could takes place.

This is already true in core.

[codedust]

We don't have to think about possible solutions here. The Signal Protocol does already exist and provides strong security guarantees. Implementing the Signal Protocol should be the way to go.