Threat model and mitigations for XChaCha20 counter-based encryption

[tasket]

The current implementation of encryption includes a combination of XChaCha20 and XChaCha20-Poly1305 ciphers with a counter-based nonce and without any re-keying. This presents a challenge to prevent nonce reuse, so the following steps are taken to protect nonce unique-ness:

Mitigations:

• Timestamp + 80-bit rnd concat-ed to counter
• Monotonic timer used for archive.ini ts and nonces – archive.ini ts cannot go backward
• Won't run if archive has ts later than 'now'
• Won't run if remote archive.ini ts is older than local
• Won't run with wrong system epoch
• Counters saved with buffering=0 and flush()
• Always use the largest known counter, keyfile vs archive.ini
• Encryption is always initialized at startup with known counter value + 2X the cadence value (recently changed from 1X cadence)
• Always display archive ts when accessing archive

An additional factor is the cadence Wyng uses to update locally-cached files with counter and timestamp info:
During send operations, archive.ini and archive.ini.salt have cadences of 100 and 20, respectively.

Relevant mishaps or attacks include:

• Rollback of the remote storage (the archive)
• Misconfiguring the system clock backward
• Rollback of local admin environment storage or deletion of Wyng cache

The causes of these conditions can be explored below, such as when describing a use case scenario in detail to gain better understanding.

Any 1 or 2 of these occurring in one session would not pose a problem. However, all 3 together might allow a nonce reuse situation if the 80-bit rnd repeats values used alongside a set of timestamps + counter values that were sent during and after the affected archive's latest session/snapshot. This would constitute a type of replay attack.

Recommendations:

1. When using this mode and the system has either recently crashed during a backup or been reset/reinstalled, use wyng list and note the 'updated' timestamp. Then, check that your current system time is correct.

   Next, performing any write operation with send, prune, etc. will advance the archive metadata so as to remove the possibility of nonce reuse.

2. Or alternately, use a different encryption mode that resists nonce reuse (not yet implemented) recommended by libsodium for XChaCha20: Either a 192-bit rnd or the hash of a rnd + message concat. The choices here may affect the speed of send operations. See documentation for arch-init on selecting the encryption mode.

Constructive comments are welcome!

Possible Future Mitigations:

• Automatically place the archive into a read-only mode whenever Wyng must fetch metadata root from remote under certain conditions (no metadata in cache, or when cache is older/newer than remote). To return to write mode, user would have to manually vouch that the system clock is correct, and Wyng would respond by updating the metadata root with the current time. This takes the guesswork (or having to remember recommendation no. 1) out of ensuring the safety of counter mode encryption.

• Derive nonces strictly from the plaintext's hash value, with no random component. This could offer an interesting trade-off in safety where the downside is further mitigated by Wyng's hierarchical integrity checks (and the fact that repeated chunks can be known by their dedup hardlinks anyway).

• Implement Re-keying.

Related issues and commits:

• Make all 192 bits of nonces random #155
• Derive the ChaCha20 key from the long-term key and the data hash #157
• Add encryption using libsodium keyed-hash nonce recommendation #159

[tasket]

Update: Changed recommendation no. 1 to offer an affirmative and relatively simple solution when using the counter mode.

Future... Possibly detect any mundane crash condition during archive writes. This could prevent any further writing (hence preventing nonce reuse) until the user has signaled the system time is correct and the metadata can be advanced. This reduces the gap scenarios to ones where the admin system has had a major upheaval, such as a wipe or (re)install; in those cases the system time would still have to be checked, but Wyng might not be able to tell if it should treat the archive as read-only.

Alternately, the counter mode could treat the archive as read-only in any/all cases where it does not already have an established cache of metadata for that archive; a special option would instruct the user to check system time before advancing the metadata and re-establishing the cache.