node-cookie-signature

Summary With ~29 million weekly downloads and usage in 1,174+ npm packages, is a critical piece of infrastructure for session management, CSRF protection, and authentication flows in the Node.js ecosystem. Since cookie signing/verification occurs on the hot path for every authenticated HTTP request, even small performance improvements can yield significant benefits at scale. I've identified several optimization opportunities that could improve performance while maintaining security guarantees. These optimizations are particularly valuable for high-traffic applications where HMAC computation becomes a bottleneck. Proposed Optimizations 1. HMAC Result Caching with LRU Problem: The current implementation recomputes HMAC signatures for every call, even for identical cookie values that are verified repeatedly (common in session-based authentication). Solution: Implement an optional LRU cache for HMAC verification results. \\\${input}:\${secret}\\${input}:\${secret}\\ Impact: Research shows RAM caching can reduce CPU cycles by ~65% for cookie verification (source). For high-traffic applications with 10,000 RPS, this could save significant CPU resources. Security Note: Cache invalidation should be time-bounded (TTL) to prevent stale signatures from being accepted indefinitely. 2. Single-Pass Buffer Allocation Problem: The current implementation creates multiple intermediate buffers during verification: Two string-to-buffer conversions (\, \) Unnecessary buffer allocation in the \ function called during verification Solution: Pre-allocate buffers and reuse them, or use a single comparison without intermediate allocations. \\\ Impact: Reduces buffer allocations from 3 to 2 per verification, and eliminates the overhead of calling \ (which concatenates strings unnecessarily). 3. SIMD-Accelerated Base64 Encoding (for large cookies) Problem: Node's built-in Base64 encoding is not optimized for performance. For larger cookie values (JWT tokens, serialized session data), this can be a bottleneck. Solution: Use SIMD-accelerated Base64 encoding for cookies larger than ~300 bytes. \\\ Impact: SIMD-accelerated libraries can be ~6x faster than Node's Buffer for Base64 encoding on longer inputs (lovell/64). However, for short cookies (500B) Use Cases This package is used extensively in: Session management: Express, Koa, and other frameworks for signed session cookies CSRF protection: Token signing and verification Authentication flows: Stateless authentication using signed cookies API rate limiting: Signed tokens for request verification In these scenarios, cookie signing/verification is on the critical path for every HTTP request, making performance optimizations highly valuable. Offer to Help I'd be happy to: Create a benchmark suite to measure performance improvements Implement these optimizations as a PR with comprehensive tests Work on backward compatibility and optional feature flags These optimizations maintain security guarantees (timing-safe comparison, proper HMAC usage) while significantly improving throughput for high-traffic applications. Would you be open to exploring any of these optimizations? I'm happy to start with a focused PR on one or two of these improvements. References**: High Performance HMAC Cookie Signing Node.js crypto one-shot optimization discussion SIMD-accelerated Base64 encoding Node.js performance discussions on hashing

A bit of recent activity here (posed as a feature request but after reading more carefully I think just needed some help using existing functionality, or consider the older #33 idea for example, but regardless…) has me thinking about the maintenance of this library. Context: I seem to have ± inherited it from TJ years ago, at least I am able to push to this repository (though not change settings on it) as well as publish releases on npm, and I seem to be the only one proactively responding to discussions here. So afaik I am in practice the only current maintainer. This isn't a huge problem, since my vision for this particular library is that it remain a simple, stable, secure piece of reusable code. The easiest way to do that has been to simply not mess with it unless/until another security issue ever comes to light. So I answer the occasional question or address a maintenance issue every now and then but that's it. So I'm happy to keep doing that, but it's not an ideal situation for the users of this library. As an open source project it should be more responsive to the hopes and dreams of its users. Even if this library is already in an "actively finished" state it doesn't seem right for me to make that declaration unilaterally. as critical infrastructure it should have more formal review/release process, vulnerability disclosure point-of-contact, etc. etc. I think it'd be good for this library to find a more "sustainable" home ~~this year~~one of these years! IIUC, the https://github.com/senchalabs/connect project (and therefore also the https://github.com/expressjs/express project?) still rely on this library as a critical piece of their session-handling infrastructure. Assuming TJ would be on board, I wonder if this repository could be moved to one of those accounts and be maintained under the umbrella of one of those communities?

https://nodejs.org/dist/latest-v20.x/docs/api/crypto.html#cryptosubtle CC/ @natevw