Negating the risk of a random 64-bit nonce Given a stream cipher such as Chacha20, which uses a 64-bit nonce, it would be unsafe to use a random nonce because of the risk of accidental repetition (which if used twice with the same key would be disastrous). In environments where using a simple counter is not an option, consider the following construction:


staticKey: 256 bit cryptographically secure pseudorandom key
perEncryptionSalt: 128 bit random salt
perEncryptionKey: HKDF(staticKey, perEncryptionSalt, info)
perEncryptionNonce: 64 bit random nonce


Ciphertext = chacha20(clearText, perEncryptionKey, perEncryptionNonce)

The salt and nonce would be appended to the ciphertext and included in the mac. Given that the key changes with each encryption (and thus would unlikely ever be used in combination with the same nonce), is this construction safe? I'm aware of XChacha20/XSalsa20 and they already solve this problem, but I'm curious nonetheless.
Without looking at the code I would say your construction is pretty much the same as XChaCha20:

From https://download.libsodium.org/doc/advanced/xchacha20.html


  Internally, XChaCha20 works like a block cipher used in counter mode.
  It uses the HChaCha20 hash function to derive a subkey and a subnonce
  from the original key and extended nonce, and a dedicated 64-bit block
  counter to avoid incrementing the nonce after each block.


(emphasis mine)

I'm not sure if this HChaCha20 hash function has any specific properties but using HKDF is probably just fine.

Here is the paper on XSalsa20. It should be possible to adapt the security proof.