File Encryptor & Decryptor

Introduction:

File encryption protects the contents of a file after it leaves the place where it was created. A copied archive, exported spreadsheet, backup, log sample, or shared attachment can still be lost, forwarded, intercepted, or stored in the wrong folder. Encryption changes the readable bytes into ciphertext so that possession of the file is not enough to read it.

Password-based file encryption adds a practical tradeoff. A password is easy to store in a password manager and share through a separate channel, but it is not strong enough to use directly as a cipher key. A key derivation function combines the password with a salt and a work cost, then produces the key bytes used by the cipher. The salt prevents identical passwords from producing identical derived keys, and the work cost raises the price of offline guessing.

Modern encrypted files also need integrity protection. Confidentiality hides the content, while authentication detects whether the ciphertext or required context changed. AES-GCM is commonly chosen for new files because it combines encryption with an authentication tag. Older modes such as CBC, CTR, CFB, and OFB can be necessary for compatibility, but they need stricter recovery notes and, for non-authenticated flows, a separate integrity check.

Recovery metadata is as important as the ciphertext. Decryption needs the same password, salt, key derivation settings, cipher, IV or nonce, padding rule when applicable, and any additional authenticated data. An envelope format keeps much of that information with the encrypted file. Raw ciphertext and compatibility formats can be useful, but they turn metadata preservation into a manual task.

Password strength remains the main human risk. A short or reused password can be guessed offline if an attacker obtains the encrypted file. A long unique passphrase stored separately is usually more useful than a complicated short password that nobody can type or recover accurately.

Encryption should be tested before trust is placed in it. If the only plain copy is deleted before a test decrypt, a wrong password entry, missing salt, changed KDF cost, damaged file, or lost envelope can turn a confidentiality control into a permanent lockout.

How to Use This Tool:

Use the recommended path for new files unless a recipient or legacy payload requires different settings. Compatibility options are available for recovery work, not as stronger defaults.

1. Choose or drop one file. Replace the demo file before working with real data.
2. Set Operation to Encrypt file for a new protected output or Decrypt file when you already have a matching envelope, raw payload, or OpenSSL Salted__ file.
3. For new encrypted files, keep AES-GCM (256-bit), Envelope (.stenc), and the balanced Argon2id profile unless your receiving workflow requires another format.
   AES-GCM uses an authentication tag. If the browser cannot provide secure AES-GCM support, use a secure context such as HTTPS or localhost before creating new protected files.
4. Enter a long unique passphrase. Store it separately from the encrypted output and do not reuse a password from an account, archive, or previous handoff.
5. Open Advanced only when you need exact compatibility. Balanced Argon2id uses 19 MB and 2 passes, hardened Argon2id uses 64 MB and 3 passes, and compatibility PBKDF2 uses 600,000 SHA-256 iterations.
6. If you choose raw output, record the salt, IV or nonce, algorithm, KDF settings, encoding, padding, and AAD exactly.
   Raw output keeps less recovery information with the ciphertext. A one-character error in salt, IV, AAD, or KDF cost can make decryption fail later.
7. After processing, download the result and review Evidence Ledger, Payload Footprint Map, Recovery Runbook, and JSON before deleting originals or sending the encrypted file.

Interpreting Results:

The posture badge is a settings review, not a guarantee against all future attacks. Posture: Hardened means the selected cipher, packaging, KDF cost, password score, and integrity choices meet the page's stronger rule set. Posture: Balanced is a practical middle state. Posture: Compatibility Risk means legacy choices, raw packaging, low KDF cost, weak password signals, or missing integrity protection should be fixed before sharing or long retention.

The password score is deliberately simple. It checks length, mixed case, digits, and symbols. It does not know whether the passphrase has appeared in a breach, was reused elsewhere, or follows a predictable phrase pattern. For file encryption, length and uniqueness usually matter more than decorative complexity.

Evidence Ledger is the recovery checklist. Confirm the mode, format, algorithm, KDF, salt, IV or nonce, AAD byte count, authentication tag or HMAC status, original size, output size, and download name. Payload Footprint Map compares byte counts so you can spot the expected overhead from metadata, nonce, tag, encoding, and packaging.

Recovery Runbook turns risky settings into concrete follow-up steps, such as switching to AES-GCM with envelope packaging, raising KDF cost, enabling an HMAC sidecar for non-AEAD modes, or storing metadata next to a raw payload. JSON is the structured audit record for tickets, runbooks, or handoff notes.

A decrypt failure does not prove the password alone is wrong. The same error can come from a missing salt, wrong IV or nonce, AAD mismatch, changed KDF settings, wrong cipher, wrong padding, corrupted bytes, or failed authentication. If HMAC valid is No, treat the output as untrusted even if some bytes appear readable.

Technical Details:

Password-based encryption has three linked mechanisms. Key derivation stretches the passphrase into key material. The cipher uses that key, an IV or nonce, and the file bytes to produce ciphertext. Packaging then decides which recovery facts travel with the encrypted result and which must be preserved elsewhere.

AES-GCM is an authenticated encryption mode. For the supported AES-GCM choices, the file uses a 12-byte nonce and a 16-byte authentication tag. The tag is checked during decryption, and additional authenticated data is included in that check when supplied. If the AAD changes, decryption should fail even though the AAD itself is not encrypted.

Mechanism Path

KDF Choices

Argon2id is memory-hard, so it raises both memory and CPU cost for password guessing. PBKDF2-HMAC-SHA256 is widely supported and useful for interoperability, but it is not memory-hard. Whichever KDF is used, the salt must be preserved because the same password with a different salt produces different key material.

Cipher and Packaging Effects

Password Score Signals

Privacy and Recovery Notes:

Encryption and decryption run in the current browser. The selected file, password, generated salt, IV or nonce, and decrypted output are not uploaded as part of the file processing workflow. A network connection can still be used to load the page and supporting browser resources, so do not treat the page load itself as an air-gapped environment.

• Losing the passphrase usually means losing access to the encrypted file.
• Envelope files reduce metadata loss, but they do not store the password.
• Raw payloads need exact external notes for salt, IV or nonce, algorithm, KDF settings, encoding, padding, and AAD.
• Test-decrypt a copy before deleting the original file or relying on an encrypted archive.
• Use organization-approved key management, retention, backup, and compliance controls when policy requires them.

Worked Examples:

New confidential export

A spreadsheet export is encrypted with AES-GCM, envelope packaging, balanced Argon2id, and a long unique passphrase. The downloaded .stenc file carries the algorithm, salt, nonce, KDF settings, encoding, ciphertext, and recovery facts. The passphrase is stored separately, and a test decrypt is completed before the plain export is removed.

Raw ciphertext that cannot be opened later

A Base64 raw payload is saved without its salt. The IV can be read from the start of the raw bytes, but the salt is still missing. The same password cannot derive the same key without that salt, so the recovery runbook should identify the missing value as the blocker.

OpenSSL compatibility handoff

A partner asks for an OpenSSL Salted__ payload. AES-CBC and the agreed PBKDF2 iteration count are used only for that compatibility requirement. The Evidence Ledger is exported with the file so the recipient can confirm format, salt, padding, and iteration count before decrypting.

FAQ:

Glossary:

AES-GCM

An authenticated encryption mode that protects confidentiality and checks an authentication tag during decryption.

Argon2id

A memory-hard password derivation function that raises memory and CPU cost for offline guessing.

PBKDF2

A password-based key derivation function that repeats a hash operation many times. It is widely compatible but not memory-hard.

Salt

A random value mixed into key derivation so identical passwords do not produce identical derived keys.

IV or nonce

A per-encryption value required by the cipher mode. Reuse or loss can break security or recovery.

AAD

Additional authenticated data. It is not encrypted, but authenticated modes check it during decryption when it is used.

References:

• FIPS 197: Advanced Encryption Standard (AES), NIST, updated May 2023.
• NIST SP 800-38D: Galois/Counter Mode (GCM) and GMAC, NIST, 2007.
• NIST SP 800-132: Recommendation for Password-Based Key Derivation, NIST, 2010.
• RFC 9106: Argon2 Memory-Hard Function, IRTF, 2021.
• Web Cryptography Level 2, W3C.
• NIST SP 800-63B: Authentication and Lifecycle Management, NIST.