Add encryption using libsodium keyed-hash nonce recommendation

[tasket]

Per libsodium documentation, XChaCha20 nonces generated from keyed hashes are recommended to mitigate the possibility of nonce reuse. This has security advantages for a multi-session format like Wyng.

The recommended form is Hk( rnd || m ) where Hk is a keyed hash function like BLAKE2 or HMAC. The latter, HMAC, presents the possibility to use a faster hashing engine such as KangarooTwelve which is available in newer versions of PyCryptodome (the crypto library used by Wyng).

Question: There appears to be little/no guidance on the 'rnd' size. My inclination is to make it the same size as the nonce (i.e. 24 bytes), but maybe there are better choices?

Related issues:
#157
#158
#161

[tasket]

@DemiMarie @marmarek Added the keyed-hash encryption mode. It can be accessed via the test name 'xchacha20-t1' when creating a new archive, like so:

sudo wyng arch-init --dest=file:/mnt/drive1/test.backup --local=vg1/pool1 --encrypt=xchacha20-t1

[tasket]

Testing notes:

Hashing the plaintext does have a noticeable impact on performance when sending to a very fast storage medium.

Backup times for a volume holding 12GB data:

Runtime (sec)	Wyng Encryption Mode	Nonce Method
68.7	xchacha20	XChaCha20 concat counter
83.8	xchacha20-t1	XChaCha20 BLAKE2b Hk(rnd||m)
68.0	xchacha20-t2	XChaCha20 rnd nonce
76.3	xchacha20-t3	XChaCha20 HMAC-SHA256 Hk(rnd||m)*
68.5	n/a	XChaCha20 BLAKE2b Hk(rnd||pthash)

The -t3 mode may not be usable as-is since I merely truncated the HMAC digest to fit in the 192-bit nonce (which appears to be OK in practice, see HMAC note below). Its still interesting to see the performance difference vs. BLAKE2b (-t1).

The last entry, improvised, doesn't have a mode. Its a simple re-use of the Wyng manifest hash of the plaintext, prefixed with rnd and fed into a keyed hash function.

The first 3 in the table are all libsodium recommendations, and I'm currently inclined to keep them as some type of option. The last 3 haven't yet been pushed to github.

[tasket]

KangarooTwelve: This doesn't appear to be a near-term option since the @Legrandin Cryptodome version is running slower than BLAKE2b in my comparison tests. It would have been great to be able to pair it as HMAC-K12 to obtain a more performant keyed hash with a select-able output size.

[DemiMarie]

What about using the keyed hash as the key, as well as the nonce, for plain ChaCha20 (instead of XChaCha20)?

[tasket]

That is intriguing, being both fast and deterministic...I think its the same as the issue #157 you posted, right?

TBH, it stretches my head somewhat beyond my comfort zone on this topic. And it has one additional complexity hurdle that I don't think was expressed in that issue: The manifest hashes are themselves encrypted, albeit under a separate key from the data; that could mean having to encrypt the metadata in a special way. We can continue discussion in 157.

[tasket]

HMAC Truncate:

In the HMAC RFC 2104 truncating to 192 bits is OK...

5. Truncated output

Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t (namely, the computation is carried in the normal way as defined in section 2 above but the end result is truncated to t bits). We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits [...]

So that means the -t3 method also fall into the libsodium recommended category, assuming they do not themselves place additional restrictions on the use of HMAC output.

[tasket]

The xchacha20-t3 mode is now available for testing.

Differences from its sibling -t1:

• Faster, due to hardware accelerated HMAC-SHA256 instead of BLAKE2
• Uses a subkey for the HMAC nonce generator

As usual, these modes can be used by creating a new archive with wyng arch-init --encrypt=modename

---

FYI: These -tN testing modes may or may not make it into the beta version, but if they do they will be re-named to something more relatable.

Also, there will likely be an xchacha20-t4 mode as well that uses the manifest hashes in some way.

[tasket]

If there are no objections, within a couple weeks' time I'd be ready to make the xchacha20-t3 mode the default setting for Wyng going forward.

We know it has good security, being a recommended method, and performance isn't bad on systems with SHA-256 acceleration.

---

Its likely I'll drop the xchacha20-t1 and aes-256-siv modes as they are slow and there is no advantage to keeping them.

[tasket]

The data hashing algorithm for xchacha20-t3 (and -t2) has been changed to the much faster HMAC-SHA256. As a result, if you created older -t2 or -t3 archives their data will no longer be recognized as valid!

You are urged to create new -t2 and -t3 archives in that case.

(If you created archives under the old default xchacha20, they will still be handled the same way and data recognized as valid. A counter mode is still select-able as xchacha20-tc which now uses HMAC for faster data hashing.)

[tasket]

An extra precaution was added to make the subkeys more robust. Their size has been increased to 512 bits and they now have independent 512 bit salts (slots 2 and 3) and separate contexts and separate iterations within those contexts. The subkey hash algorithm has also been changed to SHA-512. Primary keys (slots 0 and 1) now use 512 bit salts as well. This is being done to ensure ample key differentiation and strength.

This change also means if you were using any of the -tX encryption modes, those archives won't work with Wyng version 20230528 onward ...again. (Sorry about that!)

[tasket]

The encryption mode selection names have been decided. Here is a quick rundown of the changes:

Deprecated:

xchacha20 — This is the original counter mode, which is replaced by slightly better counter mode below. This mode will continue to function for existing archives.

Removed:

xchacha20-t1 and xchacha20-t2 — No longer present in code.

Accepted:

xchacha20-t3, xchacha20-t4 and xchacha20-tc — These modes have been renamed xchacha20-msr, xchacha20-dgr and xchacha20-ct, respectively. The last option is the name going forward for the protected counter mode.

Also, the default encryption setting will be xchacha20-dgr from #161, which uses the 'Hk || rnd' amalgam for generating nonces under the data key and the simpler-to-implement but slower 'm || rnd' for metadata.