File Encryptor & Decryptor

Field	Value	Copy
{{ row.k }}	{{ row.v }}
No details available.

File encryption turns readable bytes into ciphertext that only someone with the correct password can open. It helps when you need to share or store information and still keep control of access.

Authenticated encryption adds a proof that nothing changed and that the correct secret was used, so decryption either succeeds cleanly or fails. Here you can protect a file with a password, record the context that will be required later, and keep everything portable for future use.

You choose an algorithm and enter a password, then optionally add associated data that must match at decrypt time. Results can be saved as a compact envelope that preserves essential details such as algorithm, nonce, and salt so the file can be unlocked later without guesswork.

A practical example is encrypting a contract before sending it to a vendor so only recipients with the passphrase can open it. If you save an envelope, the vendor receives all needed parameters except the secret itself.

Use long passphrases and fresh nonces for each file. Very short secrets or reused values reduce protection, and mismatched associated data will correctly make decryption fail.

Technical Details:

Authenticated encryption with associated data (AEAD) protects confidentiality and integrity in one step. The plaintext bytes of the file are transformed into ciphertext using a key derived from a password, a per‑file random salt, and the chosen key‑derivation settings.

Key derivation uses either Argon2id with time and memory cost or PBKDF2 with HMAC‑SHA‑256 and an iteration count. A unique salt is generated when not supplied. The derived key length matches the selected algorithm’s requirement.

Results can be saved as a portable JSON envelope (.stenc) that includes algorithm, key‑derivation label, nonce or IV, salt, optional associated data, encoding, creation time, and the ciphertext, along with the original file name and size. A “Raw” option stores only nonce or IV concatenated with ciphertext using the selected encoding.

AES‑GCM is available with 128‑bit or 256‑bit keys. ChaCha20‑Poly1305 and XChaCha20‑Poly1305 are available with 32‑byte keys and 12‑byte or 24‑byte nonces respectively. A group of legacy, unauthenticated ciphers is included purely for compatibility; prefer AEAD modes for new data.

Processing pipeline

Read the entire file into memory as bytes.
Generate or parse a 16‑byte salt; derive a key from the password using Argon2id or PBKDF2.
Generate or parse a per‑file IV or nonce; optionally encode associated data to bytes.
Encrypt with the selected AEAD algorithm; associated data, when present, must match at decryption.
If “Envelope,” Base64 or Hex‑encode fields and assemble a JSON object including metadata; save as .stenc.
If “Raw,” concatenate IV or nonce with ciphertext, encode as selected, and save as .enc.
Display a summary with algorithm, KDF label, IV/nonce and salt (hex), encoding, sizes, and timestamps.

Symbols & Units

Symbols and units used by the encryption process
Symbol	Meaning	Unit/Datatype	Source
`M`	Plaintext file bytes	bytes	Input
`P`	Password or passphrase	UTF‑8 string	Input
`S`	Salt for KDF	16 bytes	Generated or input
`K`	Derived key	16 or 32 bytes	Derived
`N`	IV/nonce per file	12 or 24 bytes	Generated or input
`A`	Additional authenticated data	bytes	Optional input
`C`	Ciphertext (includes tag for AEAD)	bytes	Derived
`E`	Envelope JSON object	text (Base64/Hex fields)	Derived

Worked example: Select AES‑GCM 256‑bit, enter a long passphrase, keep Argon2id at 3 passes and 64 MB, and leave IV and salt blank. The tool creates fresh random values, derives a 32‑byte key, encrypts the file with optional associated data if provided, and writes a .stenc envelope that includes algorithm, KDF label t=3, m=64MB, IV, salt, creation time, original name and size, and the encoded ciphertext. At decrypt time, supplying the same password and associated data restores the original file.

Variables & parameters

Algorithms and key parameters
Parameter	Meaning	Unit/Datatype	Typical Range	Notes
Algorithm	AEAD or legacy stream/block cipher	enum	AES‑GCM‑128/256; ChaCha20‑Poly1305; XChaCha20‑Poly1305; legacy set	Prefer AEAD choices for new data.
KDF	Key derivation function	enum	Argon2id; PBKDF2‑SHA‑256	Argon2id recommended.
Argon2id passes	Time cost	integer	≥ 1	Default 3.
Argon2id memory	Memory cost	MB	≥ 16	Default 64 MB.
PBKDF2 iterations	Work factor	integer	≥ 10,000	Default 210,000.
Associated data	Context string to authenticate	UTF‑8	optional	Must match at decryption.
Encoding	Field and output encoding	enum	Base64; Hex	Affects `.stenc` and Raw.

Validation & bounds (from the app)

Input validation rules and placeholders
Field	Type	Min	Max	Step/Pattern	Error Text
File	File	—	—	Any type; fully buffered	“Select a file and enter a password.”
Password	String	1	—	UTF‑8	Required for both modes.
Argon2id passes	Number	1	—	step 1	—
Argon2id memory	Number	16	—	MB; step 1	—
PBKDF2 iterations	Number	10000	—	step 1000	—
IV (hex)	String	0	—	Non‑hex is stripped	Auto‑generated when blank.
Salt (hex)	String	0	—	Non‑hex is stripped	16 bytes generated when blank.
Output format	Enum	—	—	Envelope or Raw	—
Encoding	Enum	—	—	Base64 or Hex	—

Randomness & reproducibility

Salts and IVs/nonces are generated with cryptographic randomness when left blank.
No seeding interface is provided; repeated runs with the same inputs can still differ due to fresh randomness.
Duplicate detection is not applicable; encryption is deterministic only when all inputs and random values are identical.

Networking & storage behavior

Processing is browser‑based; files are read locally and written with object URLs.
Cryptographic bundles for key derivation and AEAD options are fetched from a public CDN at runtime.
No server endpoints are contacted for file contents, and nothing is uploaded.

Diagnostics & determinism

A summary panel lists mode, algorithm, KDF, parameters, IV/nonce, salt, encoding, sizes, and timestamps.
A JSON view exposes the exact input parameters and output metadata for auditing.
Identical inputs with identical IV/nonce produce identical outputs; otherwise outputs differ by design.

Security considerations

Prefer AES‑GCM, ChaCha20‑Poly1305, or XChaCha20‑Poly1305 for integrity and confidentiality.
Legacy ciphers in compatibility mode lack authentication and, in some cases, use ECB; avoid for new data.
Never reuse an IV or nonce with the same key; choose fresh random values per file.
Associated data must be identical at encrypt and decrypt; mismatches correctly cause failure.
AES‑GCM requires a secure context; use HTTPS or localhost to enable the crypto engine.

Assumptions & limitations

Entire files are buffered in memory; very large inputs depend on available RAM.
Envelope stores original file name and size; treat this metadata as potentially sensitive.
Work factors are client‑device dependent; slower hardware yields slower derivation.
Hex inputs are sanitized by removing non‑hex characters silently.
Decryption auto‑detects envelopes by JSON fields; malformed JSON is treated as non‑envelope.
Raw outputs include only IV/nonce and ciphertext; losing the IV/nonce breaks decryption.
Clipboard and download helpers rely on browser permissions and user gestures.
Heads‑up AEAD tag size and internal encoding are implementation‑specific; do not assume fixed overhead beyond algorithm requirements.

Edge cases & error sources

Wrong password or associated data causes decryption failure without partial recovery.
Blank file or missing password triggers “Select a file and enter a password.”
Invalid algorithm selection raises “Invalid algorithm.”
Non‑secure context disables AES‑GCM with “requires a secure context.”
Incorrect encoding selection leads to “IV/encoding/AAD” or “nonce/encoding/AAD” failure messages.
Malformed envelope JSON yields “Envelope missing IV/nonce” or falls back to Raw path.
Non‑hex characters in IV or salt are stripped; odd‑length hex truncates last nibble.
Very long associated data increases authentication cost and must match exactly.
Clipboard failures may be blocked by permissions or cross‑origin restrictions.
Out‑of‑memory or quota limits can interrupt buffering or download creation.

Scientific & standards backing

AES‑GCM is defined in widely adopted security guidance; ChaCha20‑Poly1305 and XChaCha variants are specified in open cryptographic documents; Argon2 is the Password Hashing Competition winner; PBKDF2 with HMAC‑SHA‑256 is standardized for password‑based key derivation.

Privacy & compliance

No data is transmitted or stored server‑side. The envelope embeds algorithm parameters and ciphertext along with optional context; review internal policies when handling names and sizes of files in metadata.

Step‑by‑Step Guide

File encryption with a portable envelope keeps parameters with the result so decryption is predictable.

Choose Encrypt or Decrypt.
Add a file via drag and drop or file picker.
Select an algorithm; prefer AEAD choices.
Enter a strong password required.
Pick a KDF and adjust passes, memory, or iterations.
Optionally add associated data that must match later.
Choose Envelope or Raw and an encoding, then run.

Example: Encrypt a report.pdf with AES‑GCM 256, Argon2id at 3 passes and 64 MB, and Envelope. Decrypt later by supplying the same password and associated data.

Your result includes a download plus a readable summary for record‑keeping.

FAQ

Is my data stored?

No. Files are processed in the browser and written to a temporary download link. The app does not upload your file contents.

Envelope metadata includes algorithm details and original name and size.

Which algorithm should I choose?

Pick an AEAD option such as AES‑GCM or XChaCha20‑Poly1305 for new data. Legacy ciphers exist for compatibility and should be avoided when possible.

What does the envelope contain?

Algorithm, KDF label, IV or nonce, salt, optional associated data, encoding, creation time, original name and size, and the encoded ciphertext.

Why did decryption fail?

Passwords, KDF settings, IV or nonce, encoding, or associated data may not match. Ensure the envelope or Raw data and all parameters are correct.

Can I decrypt a .stenc file elsewhere?

Yes, the envelope is self‑describing. Any compatible tool that honors the same fields and encoding can reconstruct the parameters and decrypt with your password.

Does AES‑GCM need HTTPS?

Yes. The browser’s crypto engine requires a secure context. Use HTTPS or localhost to enable AES‑GCM operations.

How do I decrypt a .stenc file?

Select Decrypt, choose the file, enter the password, and ensure any associated data is identical to what was used at encryption.

What does “associated data” mean?

It is context that is authenticated but not encrypted. It must be identical at encrypt and decrypt, or decryption fails.

Troubleshooting

“Requires a secure context”: switch to HTTPS or localhost.
“Invalid algorithm”: reselect a supported option and try again.
“Decryption failed. Check password, KDF, and AAD.”: verify password and associated data.
“IV/encoding/AAD” or “nonce/encoding/AAD” errors: confirm encoding and IV/nonce length.
Clipboard actions fail: allow clipboard access or use download buttons.
Output looks truncated: ensure you chose the correct encoding for the input.
Very large files stall: reduce size or close other tabs to free memory.

If you no longer have the correct password or the original IV/nonce for Raw outputs, the file cannot be recovered.

Glossary

AEAD: Authenticated encryption with associated data; combines secrecy and integrity.
Associated data (AAD): Unencrypted context that is authenticated and must match at decryption.
KDF: Key derivation function; stretches a password into a cryptographic key.
Salt: Random per‑file value used by the KDF to prevent reuse attacks.
IV/Nonce: Per‑file value required by AEAD algorithms; must be unique with a given key.
AES‑GCM: Advanced Encryption Standard in Galois/Counter Mode; AEAD construction.
ChaCha20‑Poly1305: Stream cipher with authentication; AEAD construction using 12‑byte nonces.
XChaCha20‑Poly1305: Extended‑nonce variant of ChaCha20‑Poly1305 with 24‑byte nonces.
Envelope (.stenc): Self‑describing JSON that carries parameters and ciphertext together.
Raw output: IV/nonce concatenated with ciphertext and encoded as text.