Can one extend the ChaCha and Salsa20 nonces by XORing the extra nonce bits with the key?
My reasoning is as follows: the Rumba compression function allows attackers to supply any 48-byte input to the core, and HS1-SIV (a CAESAR 2nd round candidate) explicitly assumes and requires that ChaCha20 be secure in the related-key model. As the HS1-SIV authors point out, this IS secure if the ChaCha and Salsa cores are ideal $48B\rightarrow 64B$ PRFs (they XOR a MAC with the key).
Maybe. But your scheme hasn't been vetted by the community for its impact.
Better to use XSalsa20 or the related XChaCha20 as recommended by Bernstein himself: http://cr.yp.to/snuffle/xsalsa-20110204.pdf
In my opinion it was a fairly major faux pas that DJB originally chose short 64-bit nonces for Salsa20 and ChaCha20, especially given all the nonce-misuse attacks in the past. Storing a no-chance-to-repeat counter is actually really hard in practice. He then went on to make a "idiot-proof" crypto library that requires a user-supplied nonce for every "simple" box function, and yet doesn't include the nonce in the authenticated cipher text output.
Can one extend the ChaCha and Salsa20 nonces by XORing the extra nonce bits with the key?
One can, but one probably should not.
Security against related-key attacks is not claimed for either (Salsa20 security pdf):
The standard solutions to all the standard cryptographic problems—encryption, authentication, etc.—are protocols that do not allow related-key attacks on the underlying primitives. I see no evidence that we can save time by violating this condition. The reader might guess that Salsa20 is highly resistant to related-key attacks; but I simply don’t care.
The XSalsa20 cipher, or an equivalent construction from ChaCha20, is a way to extend the nonce that has a security proof (pdf), so it is the one that I would recommend.
