Three Experiments and Keys
This tool, "Web Crypto API Tester & Encryption Lab", is an experimental laboratory for visually verifying operations of the window.crypto.subtle interface standard in modern browsers.
Switching between tabs for three distinct cryptographic algorithms (AES-GCM, RSA-OAEP, and HMAC-SHA256), users can execute key generation, data encryption and decryption, or shared-secret MAC generation and verification step-by-step.
Transformations on entered text and generated key data execute inside the browser, immediately reflecting results across on-screen fields.
Each tab places a "Generate Key" action in its initial step. In this lab, calling the API's generateKey method exports binary data from the resulting CryptoKey object and displays it as a string on screen.
Setting the exportable flag (extractable: true) is strictly for educational demonstration to visualize key structure (such as Base64 or JWK formats).
Generated keys remain solely in transient memory and disappear upon reloading the browser or closing this page tab. Switching between AES, RSA, and HMAC tabs preserves key states.
Modifying HMAC plaintext or verification values clears previous verification results, while altering AES or RSA ciphertext clears decryption outputs.
Simply changing plaintext does not clear existing ciphertext.
AES IV and Decryption
The symmetric cipher tab explores text encryption using authenticated AES-GCM (256-bit). Executing "Generate Key & IV" outputs a Base64-encoded shared key and a 12-byte initialization vector (IV) in HEX format.
Entering plaintext and executing encryption converts the text to bytes internally with TextEncoder, producing cipher data using the specified key and IV.
An important specification is that clicking the encrypt button regenerates a fresh 12-byte IV via window.crypto.getRandomValues each time.
Under the AES-GCM standard, reusing the same IV with identical keys creates a critical security vulnerability, so this lab applies a fresh IV on every run and updates the HEX string display accordingly.
Output Base64 ciphertext can be copied to the clipboard for decryption testing. When executing decryption, restoring plaintext via TextDecoder succeeds only when the shared key in memory, the most recently used HEX IV, and Base64 ciphertext match strictly.
If inputs do not align, an exception occurs and a failure message is output to logs.
RSA and Length Limitations
The asymmetric cipher tab simulates public-key cryptography using RSA-OAEP (2048-bit modulus length, public exponent 65537, SHA-256 hash function).
Executing keypair generation displays public and private keys as JWK (JSON Web Key) formatted strings. Because the JWK format structures key attributes (kty, n, e, d, etc.), it is well-suited for inspecting asymmetric components visually.
This lab does not import external keys; encryption and decryption testing is performed using this generated pair.
Encrypting plaintext with the public key encounters a limitation specific to this system. When using 2048-bit RSA-OAEP with SHA-256, the maximum input data size is limited to 190 bytes in UTF-8 encoding.
Attempting to encrypt text exceeding this length causes pre-validation (rsaOaepInputBytes) to throw a boundary error exception and halt execution.
This constraint is an asymmetric specification distinct from block ciphers, implemented to demonstrate why RSA is used for key exchange rather than direct long-text encryption.
Generated Base64 ciphertext can be tested for decryption using the private key.
HMAC Generation and Verification
The shared-secret MAC tab evaluates HMAC-SHA256 (256-bit) to verify data integrity and authenticity. Generating a key sets a single raw Base64 key used for both signing and verification.
Executing "Generate HMAC (MAC)" applies window.crypto.subtle.sign to entered plaintext, displaying the resulting ArrayBuffer signature as a HEX string.
Reading HEX values for verification employs strictHexBytes to strip whitespace and confirm a 64-character hexadecimal string. Format defects trigger input errors, while correctly formatted but mismatched values yield verification failure.
The generated signature is automatically copied into the lower verification field to facilitate testing.
The "Verify Signature" action cross-checks current plaintext payload, the verification field's HEX signature, and the in-memory HMAC key.
If window.crypto.subtle.verify returns true, "Valid (Signature Matches)" is displayed. Matching is confirmed under identical key, plaintext, and MAC.
Altering plaintext or MAC values demonstrates mismatch behavior upon re-verification. HMAC is not an asymmetric digital signature; verifiers must hold the same secret key, and it does not prove signer identity to third parties.
Changing plaintext clears previous verification outcomes to prevent mixing obsolete evaluations with new inputs.
Reading Generated Code
As an interactive feature, operating UI controls (such as key generation or encryption) dynamically generates JavaScript code snippets at the bottom of each tab.
These snippets serve as boilerplate implementation examples for real-world web development.
A key aspect of reading the code is recognizing that Web Crypto API operations are asynchronous Promises handled with await. For example, AES-GCM encryption code sequentially outlines converting text to Uint8Array bytes via TextEncoder, generating a 12-byte IV with getRandomValues, and passing parameters to crypto.subtle.encrypt.
Text entered in the UI is safely escaped and embedded via JSON.stringify to avoid syntax errors. Snippets also illustrate converting encrypted binary buffers to Base64 or mapping ArrayBuffers to HEX strings, demonstrating API binary handling concretely.
Generated snippets serve educational purposes rather than standalone applications; running them in external environments requires supplementary variables and helper functions such as base64ToArrayBuffer.
Additionally, helper snippets like String.fromCharCode(...bytes) can exceed maximum call-stack argument limits on large byte sequences, whereas the interactive tool handles binary buffers directly.
Snippets can be copied using the top-right button.
Key Volatility and Differences from Production
While data transformations run within the browser, design differences exist between this lab environment and secure production application architectures.
As noted, CryptoKey objects are generated with exportable flags enabled for structural inspection and held temporarily in memory.
Consequently, reloading the browser or closing the tab removes active UI state and makes generated keys inaccessible through this tool; however, this does not guarantee instantaneous zeroization in JavaScript engine memory or removal of residual OS-level traces.
In production systems, displaying sensitive keys (private or shared keys) on screen or pasting them into generic text editors is not recommended.
Production architectures design key usage scopes, storage locations, and access privileges, considering non-exportable configurations or dedicated Key Management Services (KMS).
Simply storing keys in IndexedDB does not make them secure, whereas non-exportable keys can still perform permitted cryptographic operations.
This tool is an educational demo for learning Web Crypto API interfaces and parameter behaviors, lacking production prerequisites like strict key protection, user authentication, or persistent database storage.
Do not input production keys or confidential operational data.