Andrea Maria Piana 23f71c1125 Fix encryption id && rekey with a single message
This commit changes the format of the encryption id to be based off 3
things:

1) The group id
2) The timestamp
3) The actual key

Previously this was solely based on the timestamp and the group id, but
this might lead to conflicts. Moreover the format of the key was an
uint32 and so it would wrap periodically.

The migration is a bit tricky, so first we cleared the cache of keys,
that's easier than migrating, and second we set the new field hash_id to
the concatenation of group_id / key_id.
This might lead on some duplication in case keys are re-received, but it
should not have an impact on the correctness of the code.

I have added 2 tests covering compatibility between old/new clients, as
this should not be a breaking change.

It also adds a new message to rekey in a single go, instead of having to
send multiple messages
2023-10-24 20:48:54 +01:00
..
2021-11-30 20:52:47 +02:00
2020-01-06 10:17:23 +01:00

protocol/encryption package

Hash ratchet encryption

encryptor.GenerateHashRatchetKey() generates a hash ratchet key and stores it in in the DB. There, 2 new tables are created: hash_ratchet_encryption and hash_ratchet_encryption_cache. Each hash ratchet key is uniquely identified by the (groupId, keyId) pair, where keyId is derived from a clock value.

protocol.BuildHashRatchetKeyExchangeMessage builds an 1-on-1 message containing the hash ratchet key, given it's ID.

protocol.BuildHashRatchetMessage builds a hash ratchet message with arbitrary payload, given groupId. It will use the latest hash ratchet key available. encryptor.encryptWithHR encrypts the payload using Hash Ratchet algorithms. Intermediate hashes are stored in hash_ratchet_encryption_cache table.

protocol.HandleMessage uses encryptor.decryptWithHR fn for decryption.