AES-256-GCM passphrase envelope
PBKDF2-HMAC-SHA-256 derives a key-encryption key from the passphrase; it wraps a random 256-bit data key with AES-KW (RFC 3394); the data key encrypts under AES-GCM with the associated data authenticated but not encrypted. Output: v2.salt.iv.wrappedKey.aad.ciphertext.iterations.
Output
Changing the passphrase re-wraps 40 bytes instead of re-encrypting the data. The tests check this envelope against tampered ciphertext and tampered associated data, and AES-GCM itself against NIST GCM test case 16.
RSA-OAEP (SHA-256)
Public-key encryption for short secrets. The size limit is the point: a 2048-bit key encrypts at most 190 bytes, which is why real systems encrypt a data key and wrap it.
Output
Public key (JWK, abbreviated)
Cryptographic hashing
SHA-256("abc") = ba7816bf…15ad is the FIPS 180-4 example; the tests pin all three.
Hash a file (never uploaded)
HMAC — keyed message authentication
Output
Key "Jefe" over "what do ya want for nothing?" is RFC 4231 test case 2: 5bdcc146…3843. Verification compares in constant time.
Digital signatures
Output
Sign, then edit one character of the message and verify: the signature fails. The tests do this for both schemes and with the wrong public key.
Password strength and generation
Patterns:
Generate
Draws come from crypto.getRandomValues with rejection sampling, so every character is equally likely; a plain modulo would bias toward the first characters of the alphabet.
Throughput on this device
| Operation | Per run | Throughput |
|---|
Not run yet.
LSB steganography
One bit per red, green and blue channel value; alpha untouched; a 4-byte magic and a 4-byte length so extraction can tell an empty carrier from a payload. Capacity of this 256×256 carrier: . Lossless PNG preserves it; JPEG destroys it.
Every operation runs in your browser on the Web Crypto API; the content-security policy sets connect-src 'none', so nothing can be sent anywhere. Keys generated here are ephemeral and not stored.