Public nonces can be problematic for privacy when they can be considered metadata. They can also be troublesome for security if you do things like using a hash of the message as the nonce.
PASETO now derives the nonce alongside the key using HKDF on the input keying material with a 256-bit salt. Thus, the actual nonce passed to AES-CTR and XChaCha is not revealed publicly.
The nonce used by AES-256-CTR and XChaCha20 will be derived from the HKDF output (which is now 48 bytes for v3.local and 56 bytes for v4.local). The first 32 bytes of each HKDF output will be used as the key. The remaining bytes will be used as the nonce for the underlying cipher.
TripleSec, an overkill multiple encryption library by Keybase, encrypts inner nonces.
The TripleSec technique takes one futher step not suggested by Schneier, which is to protect the inner IVs with the outer encryption algorithms, and only exposing the outermost IV in the clear. Though we can't prove this makes the scheme more secure, it seems like a reasonable idea: why reveal cipher inputs if we don't have to?
As the nonce is secret as well as the key from an attacker, how much security is likely gained from these types of approaches? Would it still be meaningfully beneficial with small nonces (e.g. 64 and 96 bits)?
I assume this is quite good with XChaCha20 due to the subkey derivation.