File Encryptor & Decryptor
Encrypt a local file into an authenticated .stenc envelope or recover it in your browser with AES-GCM, PBKDF2 or Argon2id, and no upload.{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}
{{ resultName }}
{{ resultSizeLabel }} · {{ resultDigestLabel }}
| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Step | Action | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
Introduction:
File encryption protects content when storage, email, or another handoff channel cannot be trusted with plaintext. A passphrase is turned into key material, the file bytes are encrypted, and an authentication check detects a wrong passphrase or changed ciphertext during recovery.
The encrypted file and the passphrase solve different parts of the handoff. The file can travel through an ordinary channel because its contents are unreadable without the key, but the passphrase must travel separately. Storing both together removes much of the protection.
- Cipher
- The authenticated encryption method applied to the file bytes. AES-GCM combines encryption and authentication; AES-CBC needs a separate HMAC for tamper detection.
- Key derivation
- PBKDF2 or Argon2id stretches a passphrase with a random salt so each file derives different key material.
- Nonce or IV
- A fresh random value used by the cipher. It is stored with the encrypted data and does not need to be secret.
- Associated data
- Optional non-secret context that is authenticated but not encrypted. Recovery fails if it no longer matches.
Authenticated encryption can reveal that the envelope was changed, but it cannot recover a forgotten passphrase. A strong cipher also cannot compensate for a short, reused, or predictable passphrase. Long unique passphrases and a tested recovery procedure matter as much as the algorithm name.
The encrypted result is not a backup by itself. Keep the original until a test decrypt produces the expected file, then retain the encrypted envelope in more than one reliable location if it is the only protected copy.
This format is intended for recovery by the same file-encryption workflow. It is not an OpenSSL, ZIP, age, PGP, or operating-system disk-encryption format.
How to Use This Tool:
Use Encrypt to create a protected .stenc envelope and Decrypt to recover one created by this workflow.
- Choose one non-empty file no larger than 25 MiB, then enter a unique passphrase of at least eight characters. A longer passphrase is strongly preferable for sensitive files.
- For encryption, keep AES-GCM 256-bit unless a supported compatibility need calls for AES-GCM 128-bit or AES-CBC 256-bit with HMAC-SHA256.
- Choose PBKDF2-SHA256 for broad browser compatibility or Argon2id for memory-hard key derivation. Optional associated data should be a short, non-secret context label.
- Run the operation and save the resulting file. During decryption, cipher and key-derivation settings are read from the envelope rather than taken from the current selectors.
- Test recovery before deleting the original. Compare the recovered file with the source and keep the passphrase in a separate password manager or handoff channel.
Interpreting Results:
A ready .stenc file contains the ciphertext and the recovery parameters needed to rebuild the key, including the salt, nonce or IV, cipher choice, key-derivation settings, original filename, and media type. It does not contain the passphrase.
Decryption failure deliberately combines several causes. The passphrase may be wrong, authenticated bytes may have changed, the envelope may be malformed, or AES-GCM may be unavailable outside a secure browser context. Do not treat a failed attempt as proof of corruption until those causes have been checked.
The SHA-256 digest shown for a result identifies those output bytes. Compare the recovered file with a trusted original or trusted digest when exact recovery matters; a digest shown only after decryption cannot establish what the original was supposed to contain.
Technical Details:
Password-based file encryption has four consequential stages: derive key material, encrypt and authenticate the file, record the recovery parameters, and verify authentication before releasing plaintext. Every value needed to reproduce the key must remain paired with the ciphertext except the passphrase, which stays separate.
Transformation Core
| Stage | Inputs | Output or check |
|---|---|---|
| Key derivation | Passphrase, 16-byte random salt, KDF parameters | AES key material, plus a separate HMAC key for the CBC option. |
| Authenticated encryption | Key, file bytes, nonce or IV, optional associated data | Ciphertext with either a GCM tag or a separate HMAC-SHA256 value. |
| Envelope | Ciphertext, salt, nonce, authentication value, settings, original file details | A versioned .stenc JSON file whose binary fields are Base64 text. |
| Recovery | Envelope plus the same passphrase | Authentication is checked before recovered bytes are offered for download. |
Rule Core
The supported choices use fixed costs and sizes so the envelope carries a complete, repeatable recovery description.
| Choice | Parameters | Recovery rule |
|---|---|---|
| AES-GCM 256-bit | 256-bit key, 12-byte nonce, 128-bit tag | Requires a secure browser context for encryption and decryption. |
| AES-GCM 128-bit | 128-bit key, 12-byte nonce, 128-bit tag | Uses the same authenticated-envelope flow with a shorter AES key. |
| AES-CBC 256-bit + HMAC-SHA256 | 256-bit AES key, 16-byte IV, separate 256-bit HMAC key | HMAC covers salt, IV, associated data, and ciphertext before CBC decryption. |
| PBKDF2-SHA256 | 600,000 iterations | The random salt and iteration count are stored with the ciphertext. |
| Argon2id | 3 passes, 64 MiB memory, parallelism 1 | The memory cost can make processing slower on constrained devices. |
AES-GCM appends its 16-byte authentication tag to the ciphertext. AES-CBC uses PKCS#7 padding, so ciphertext grows to a complete 16-byte block, and the envelope stores a separate 32-byte HMAC. The JSON and Base64 representation add further size beyond those cryptographic bytes.
Associated data is limited to 1,024 UTF-8 bytes. It can bind a non-secret label or context to the ciphertext, but placing a secret there would expose it in the envelope.
Privacy and Recovery Notes:
File bytes and the passphrase remain in the current browser tab during encryption and decryption; they are not uploaded to a file-processing service.
- Save the complete
.stencenvelope before leaving the page. - Send the passphrase through a different channel and do not place it in associated data.
- Keep the original until a test decrypt produces matching bytes.
- Do not edit, reformat, or partially copy the envelope because authentication or parsing will fail.
Worked Examples:
Testing a protected handoff
Encrypt a disposable copy with AES-GCM 256-bit and a unique passphrase, save the .stenc file, then switch to Decrypt and recover it under a different filename. Compare the two files byte for byte before treating the envelope as a usable backup or sending it to someone else.
References:
- NIST SP 800-38D: Galois/Counter Mode, National Institute of Standards and Technology, November 2007.
- NIST SP 800-132: Password-Based Key Derivation, National Institute of Standards and Technology, December 2010.
- RFC 9106: Argon2 Memory-Hard Function, RFC Editor, September 2021.
- How to encrypt a file with a password using OpenSSL, Simplified Guide.