Worth noting that cookie-signature uses crypto.timingSafeEqual() under the hood and this implementation doesn't. This is for a few reasons

• timing safe equal is not available as part of the webcrypto apis (though it is available in some runtimes (e.g. cloudflare))
• even if we were to use the native timingSafeEqual there are open issues on node that there is a bug in the implementation
• both bun and node uses memcmp to perform a timing safe equal, which isn't actually that safe
• we are essentially performing double hmac since cookies are signed with hmac.

The safer strategy is double-hmac. Since cookies are signed with HMAC we are already performing double-hmac by checking against the signed version of the cookie.

The only real security improvement we could make would be to perform hmac again with a randomly generated key (as a lot of double hmac solutions do), but that would probably make the unsign function twice as slow for a negligible security benefit.

Things we could do

• directly compare buffer contents. This is what memcmp does, wouldn't be a significant performance hit, but also might be meaningless since reading values from js may not be constant time
• perform double hmac again, but with a random key each time
• fall back to crypto.timingSafeEqual and just add a way to polyfill for different runtimes

further reading:

• issue RE: timingSafeEqual being added to webcrypto: timingSafeEqual functionality w3c/webcrypto#270
• details on timingSafeEqual not being "safe" and moving over to double hmac: crypto: add HMAC to crypto.timingSafeEqual() nodejs/node#38488
  -double hmac: http://web.archive.org/web/20160203044316/https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/february/double-hmac-verification/

P.S. I don't know like anything about cryptography this is just what I've learned in the last 2 days trying to figure out what timing safe equal is and how/if I should polyfill it somehow. More than happy to make any changes here.