[feature] Support Nonce Misuse-Resistant Authenticated Encryption

[desimone]

Is your feature request related to a problem? Please describe.

The current algorithms available to securecookie are susceptible to nonce-reuse issues under certain conditions. I know this is very much on the radar 1,2 of the maintainers, but the effort seems tied to a v2 which I'm not sure of the status of.

Describe the solution you'd like

I'd like for sessions to use a non misuse-resistant algorithm. Options include:

• XChaCha20-Poly1305 via x/crypto/chacha20poly1305
• XSalsa-Poly1305 via secretbox which I believe the current V2 branch is using.
• AES-GCM-SIV though no "official" go package exists (someone go poke agl_ 😉 )

XChaCha20-Poly1305 seems like the best current option. It currently exists in /x/crypto, implements the aead interface, is relatively fast (no AES-NI 😭 ), and is ubiquitous.

Describe alternatives you've considered

Reinvent the wheel and reimplement/fork my own sessions package. Which, you know. Meh.

Of course, I'd be happy to help but didn't want to step on toes if this is part of a larger effort.

[elithrar]

Moving to an AEAD construct is on the list (as well as simplifying the API), but I don't have the bandwidth for it. I'd accept a minimal PR that exposes a method - e.g. UseAEAD() - that uses XSalsa-Poly1305 or XChaCha20-Poly1305 (one of - users should not have to choose). There would need to be some wrangling with the way securecookie takes pairs of keys, since we only need one here. I'd originally selected XSalsa20 for the longer nonces - 192 bits - which makes randomly generating nonces a no-brainer and effectively re-use resistant. Nonce re-use with AES-CBC + MAC is not as catastrophic as it is with the (linked) AES-GCM, and so I'm not _as_ worried / treating this as a P1.

…