In-House High-Performance JWE/JWS Core Engine

A high-performance JWE/JWS encryption/decryption and signing module, with zero dependencies (using only Node.js crypto & zlib), specifically optimized for multi-session IAM (Identity and Access Management) systems.

1. Design Philosophy

• Zero-Dependency: Utilizes only native Node.js crypto and zlib modules. Minimizes Supply Chain Attack risks and keeps the source code lean.
• Low-Level Optimization: Directly manipulates Buffers to optimize RAM and CPU usage.
• Security First: Hardened against common attack vectors such as DoS, Zip Bombs, Timing Attacks, and Information Leakage.
• Robustness: Prioritizes operational stability, fail-safe mechanisms, and resource protection.

2. Technical Architecture & Performance Optimization

This Core Engine is not just a simple wrapper; it applies deep processing techniques:

⚡ Direct Native Bindings (OpenSSL Support)

Instead of processing encryption logic with slow pure Javascript, all heavy tasks (createCipheriv, publicEncrypt, verify) are bound directly to the C++ OpenSSL layer of Node.js.

• => Speed: Comparable to compiled languages like Go/Rust for Crypto tasks.

🚀 Zero-Copy & Native Base64Url

The system completely eliminates manual regex string processing functions (which are memory-intensive and slow). Instead, it uses the Buffer.from(str, 'base64url') API (Node.js native):

• Minimizes Intermediate Memory Allocation.
• Avoids Memory Fragmentation when handling thousands of concurrent requests.

🛡️ Memory Protection (First Line of Defense)

Before any logic runs, the system applies "Hard Limits":

• JWE Max Size: 200KB.
• JWS Max Size: 50KB.
• Zip Max Output: 2MB.
• Effect: Prevents DoS attacks aiming for Out-Of-Memory (OOM) via large malicious payloads.

3. Security Hardening Features

The engine has been patched and fortified against the following vulnerabilities:

| Threat Vector | Technical Countermeasure | | :--- | :--- | | Zip Bomb (DoS) | Limits gunzipSync output to a maximum of 2MB. | | Information Leakage | decrypt only returns a generic DecryptionFailed error. Does not reveal specific Header/Key errors to prevent Enumeration. | | Timing Attacks | Uses safe comparison functions or appropriate fail-fast logic at the Header level. | | Downgrade Attacks | Hardcodes the strongest algorithms RSA-OAEP-256 and AES-256-GCM. Rejects all weaker algorithms. |

4. Operational Usage in IAM Systems

Scenarios

1. JWS (Signature): Used as Access Token (short-term).
   • Location: API Gateway.
   • Pros: Extremely fast verify, high load tolerance.
2. JWE (Encryption): Used as Refresh Token or Secure Cookie (long-term).
   • Location: Auth Service.
   • Pros: Completely hides token structure, protects session information (Session ID) stored on Client.

Best Practices

• Key Management: The module uses PEM keys. In Production, mount Keys from a Secret Manager (Vault/AWS/K8s Secrets) into RAM at startup; avoid hardcoding them.
• Error Logging: Although generic errors are returned to the Client, the system still logs details via console.error. Connect these logs to a Monitoring system (ELK, Loki) to detect attack signs.

5. Credits & Acknowledgments

This project is inspired by and based on portions of the work from psenger/jwe_example.

6. License

MIT License.