node:crypto Native OpenSSL Bindings vs Web Crypto API
- Last updated
- Prerequisites:
- Node.js crypto basics (hashes, HMAC, encryption)
- Understanding of native bindings vs JS implementations
- nodejs
- crypto
- webcrypto
- openssl
- performance
- subtle
Read at your depth
The practical view
Node has two crypto APIs. node:crypto (require('node:crypto')) wraps OpenSSL: crypto.createHash('sha256').update(data).digest('hex'), crypto.createHmac, crypto.pbkdf2, crypto.randomBytes, AES encrypt/decrypt. The Web Crypto API (globalThis.crypto.subtle) is the browser-standard API now available in Node: crypto.subtle.digest('SHA-256', data) returns a Promise of an ArrayBuffer, crypto.subtle.encrypt/decrypt, sign/verify, deriveKey. Differences: node:crypto is synchronous (or callback), returns Buffers, has many algorithms (md5, sha1, etc.); Web Crypto is async (Promise-based), works on ArrayBuffer/TypedArray, uses WebCrypto algorithm names ('SHA-256'), and only exposes the standardized algorithm set.
The same idea in other frameworks
N/A — Node.js runtime concern.N/A — Node.js concern.N/A — Node.js concern.N/A — Node.js concern.Legacy vs modern
Synchronous node:crypto vs async Web Crypto
node:crypto hash is sync and blocks the event loop on large inputs; subtle.digest() is async and offloads, keeping the loop free.
const hash = crypto.createHash('sha256').update(bigData).digest('hex'); // ❌ OLD: blocksconst hash = await crypto.subtle.digest('SHA-256', bigData); // ✅ NEW: non-blockingInterview gotchas
Context
This tests the underlying implementation — interviewers want to know both sit on OpenSSL so raw throughput is similar, and the differences are API shape and blocking behavior, not raw speed.
The mechanical answer
Both node:crypto and Web Crypto in Node are implemented on top of OpenSSL's EVP layer, so the actual cryptographic computation (AES, SHA, RSA) runs the same optimized native code — raw throughput is essentially identical for the same algorithm. The meaningful differences are: (1) BLOCKING — the sync node:crypto API runs on the main thread, so large operations block the event loop; Web Crypto is async and offloads (thread pool), so it doesn't. (2) API surface — node:crypto exposes the full OpenSSL catalog (including md5, sha1, rc4, etc.), while Web Crypto is restricted to the standardized set. (3) Ergonomics — Buffer/hex vs ArrayBuffer/base64url and CryptoKey objects. So 'Web Crypto is faster' is wrong in the raw-sense; it's non-blocking and standardized, which is often the more important property for servers.
Trap
The naive answer is 'Web Crypto is faster because it's async'. Async changes blocking behavior, not raw throughput — both use OpenSSL. Another trap: assuming Web Crypto in Node behaves identically to browsers in every edge case — algorithm/key support may differ slightly by OpenSSL build. Candidates who explain the shared OpenSSL substrate show real understanding.
Context
This probes the standardization rationale — interviewers want the portability guarantee (browser + Node) and the security-driven algorithm allow-list.
The mechanical answer
Web Crypto restricts to the algorithms standardized in the WebCrypto spec precisely so code written against it runs identically in browsers and in Node — a portability contract. The allowed set (SHA-1/256/384/512, AES-CBC/GCM/CTR, HMAC, RSA-OAEP/PSS, ECDSA/ECDH, PBKDF2, HKDF, Ed25519/X25519 in newer specs) covers the algorithms deemed safe and widely implemented; legacy/weak algorithms (MD5, RC4, DES) and Node-specific options are excluded. This means code that uses Web Crypto can be shared between client and server without rewriting, and the key-handling model (CryptoKey with usages and extractability) enforces safer defaults. The trade-off: you cannot do everything Web Crypto doesn't define — for those (e.g. scrypt, or Node-specific formats), you use node:crypto.
Trap
The naive answer is 'Web Crypto is just node:crypto renamed'. It's a restricted, standardized subset with a different key model and async shape. Another trap: assuming Web Crypto code is automatically as fast as tuned OpenSSL calls — for exotic parameters or very large inputs the async overhead and key-conversion costs can matter. Candidates who describe the portability contract and the allow-list show real depth.