Key rotation (or other measures) for PASETO v2 "local" I was looking at using PASETO's v2 "local" encryption (XChaCha20-Poly1305) to implement short-lived tokens to share claims between microservices via an untrusted client. PASETO's documentation is strong on its implementation detail, but I'm left with questions at a higher level.

Specifically, I want to avoid a scenario where an attacker could breach a key and use it to forge claims. I'm under the impression that the likelihood of an attacker brute forcing a key increases with time and quantity of encrypted data samples, so key rotation seems like a great way to limit both the time and available data related to any single key, as well as to limit the duration which any breached key would be useful for.

I see from this answer that the primary purpose of key rotation for symmetric ciphers is to limit the damage that would result if a key was breached (e.g. only the data encrypted by that specific key would be exposed). In our use case, the claims would not contain any sensitive data, so this is not a concern.

Is key rotation a valid approach to avoid an attacker being able to forge claims? Is it overkill? Is there something else I should consider?
Key rotation is important.

Besides data breaches, unintentional key disclosure happens. For example by committing an unintended file to a public GitHub repository. Also, people having access to a key today can take a copy of that key when they leave the company.

In case of PASETO, brute-forcing the key is not a concern. The key space is ginormous (2^256), so this is infeasible, no matter how much data is collected.

If you control all the applications using that key, and you probably do, key rotation should also be fairly easy to implement.