S2V for XChaCha20-Poly1305 has actually been discussed on the CFRG mailing list (and a little bit off-list between myself and others interested in this topic). The only question that hasn't been addressed at the time of the last email was, where does it fit?
XChaCha20 uses HChaCha20 to derive a 256-bit subkey between the 256-bit key and first 128 bits of the nonce. Then it uses ChaCha20 with the subkey and the remaining 64 bits of the nonce. ChaCha20 has an internal counter that goes between 0 and 2^64 - 1.
AEAD_XChaCha20_Poly1305 uses the first 32 bytes of the XChaCha20 keystream to determine the Poly1305 key for that message, then begins the encryption starting at the next block. (The remaining 32 bytes of block_counter = 0 are discarded in XChaCha20, but not in XSalsa20; this is a subtle difference that probably only makes streaming APIs easier to design and has no significant security considerations.)
With that in mind: XChaCha20 is already deriving a key from the key and (extended) nonce. And it already has an internal block counter (which side-steps counter/nonce wrapping issue that was addressed with AES-CTR in the AES-GCM-SIV design).
The simplest solution is to, instead of just trusting your CSPRNG, do this:
function crypto_aead_xchacha20poly1305siv_encrypt(msg, key) {
let nonce = Buffer.alloc(24);
sodium.randombytes_buf(nonce);
// Synthetic nonce here:
s2v(nonce, msg);
let cipher = Buffer.alloc(msg.length + 16);
sodium.crypt_aead_xchacha20poly1305_ietf_encrypt(cipher, msg, nonce, key);
return [nonce, cipher];
}
But this would be, strictly speaking, indistinguishable from XChaCha20-Poly1305 without SIV.
For context: I authored the XChaCha20 RFC draft, implemented it in pure-PHP (twice; the second time was to support 32-bit systems).
