| Field | Value | Copy |
|---|---|---|
| {{ row.k }} | {{ row.v }} | |
| No details available. | ||
{{ securityPosture.recommendation }}
File encryption turns readable bytes into ciphertext so a document, archive, or media file can be stored or shared without exposing its contents. In a password-based workflow, the result depends on more than the cipher alone: passphrase quality, key-derivation cost, integrity protection, and metadata handling all shape whether the file is both protected and recoverable.
This page encrypts or decrypts a file in the current browser session, then produces a downloadable result plus an evidence trail about the settings that were used. It is built for people who want passphrase-driven file protection without dropping to a command line, while still keeping a record of the algorithm, KDF, IV or nonce, salt, sizes, timestamps, and recovery assumptions.
The safest path in the current package is AES-GCM with envelope packaging and a strong passphrase, because that combination keeps the recovery metadata with the ciphertext and includes built-in authentication. The page also exposes raw payload modes, a Salted__ compatibility path for AES-CBC, and several older ciphers that make sense mainly when you are trying to match an existing environment rather than start a new one.
A practical example is sending a payroll workbook to a colleague who already has the agreed passphrase. If you save the output as an envelope, the bundle carries the algorithm, KDF settings, salt, IV or nonce, and original file details so the recipient does not have to guess which parameters were used.
The convenience comes with limits. The whole file is buffered in memory, raw modes require you to preserve metadata yourself, and AES-GCM in this package needs a secure browser context such as HTTPS or localhost. A failed HMAC check on non-AEAD material should be treated as a hard warning, even though the page still reports the decryption attempt.
For new files, the cleanest baseline is to leave IV and salt blank so the page generates fresh random values, choose AES-GCM, keep the output format on Envelope, and use either the balanced or hardened Argon2id preset. That gives you a self-contained bundle with authenticated encryption and a KDF posture that lines up with current public guidance for resisting offline password guessing.
The other output modes exist for narrower reasons. Raw text and raw binary are compact, but they push the burden of preserving salt, IV or nonce, algorithm, encoding, and KDF settings onto you. The Salted__ options are useful when you need an AES-CBC compatibility wrapper, but successful recovery still depends on matching the password, AES-CBC choice, padding, and PBKDF2 iteration assumptions used at creation time.
Additional authenticated data is most useful when the file should only open in a specific context, such as a case ID or project string that must match at decrypt time. The HMAC switch matters mainly for non-GCM workflows, because AES-GCM already includes an authentication tag and will fail decryption when the data or context no longer matches.
| Goal | Best fit in this package | Reason |
|---|---|---|
| Protect a new file for later recovery | AES-GCM, Envelope, Argon2id balanced or hardened, random IV and salt | Keeps recovery metadata with the ciphertext and uses authenticated encryption. |
| Match an AES-CBC Salted__ workflow | AES-CBC plus one of the Salted__ output modes | Produces a compatibility wrapper that stores a salt header and AES-CBC ciphertext. |
| Carry a compact raw payload into another controlled system | Raw or Raw Binary, with manual metadata tracking | Reduces packaging overhead, but makes you responsible for preserving the matching parameters. |
The package supports encryption and decryption of a single loaded file. For new encryption, it reads the entire file into memory, derives key material from the password with either Argon2id or PBKDF2-HMAC-SHA256, prepares an IV or nonce of the required length, then encrypts with the selected algorithm. For AES-GCM the page uses authenticated encryption with a 128-bit tag; for the other modes it uses compatibility-style encryption and can attach an HMAC sidecar.
Algorithm choices are broader than the recommended path. AES-GCM is available in 128-bit and 256-bit forms. AES-CBC, AES-CTR, AES-CFB, and AES-OFB are available in 128-bit, 192-bit, and 256-bit variants. Legacy compatibility options include DES-CBC, TripleDES-CBC, RC4, and Rabbit. Those older choices can still be useful for migration work, but they do not offer the same default integrity story as AES-GCM.
The KDF presets mirror the page's security posture logic. Balanced Argon2id uses 19 MB and 2 passes. Hardened Argon2id uses 64 MB and 3 passes. The compatibility preset switches to PBKDF2-HMAC-SHA256 at 600,000 iterations. Those numbers are not arbitrary: they closely track public OWASP guidance, which is why the runbook warns when Argon2id drops below 19 MB and 2 passes or when PBKDF2 stays below 600,000 iterations.
Output packaging changes what is preserved alongside the ciphertext. Envelope mode writes a .stenc JSON bundle containing the algorithm, KDF name and parameters, salt, IV or nonce, padding when relevant, ciphertext encoding, creation time, original file name and size, ciphertext body, and optional AAD or HMAC. Raw mode writes IV or nonce plus ciphertext as encoded text. Raw Binary writes the same pair as binary bytes. The Salted__ options produce an AES-CBC payload with a salt header and either Base64 or binary output.
Decrypt mode works in the opposite direction. It first tries to recognize an envelope, then a Salted__ payload, then raw text, then raw binary. If the material does not carry enough metadata, the page depends on the current form settings for algorithm, encoding, padding, salt, and any required AAD. That is why raw outputs are compact but fragile: losing the side metadata can make the ciphertext impossible to recover.
| Area | Current package behavior | Why it matters |
|---|---|---|
| KDF engine | Argon2id or PBKDF2-HMAC-SHA256 | Determines the cost of turning the password into key material. |
| IV or nonce | Generated automatically when blank, or accepted as hex input | Must match at decrypt time; reuse with the same key is unsafe. |
| AAD | Optional UTF-8 string for AES-GCM workflows | Binds the ciphertext to external context and must match during decryption. |
| Integrity | AES-GCM tag or optional SHA-256 HMAC sidecar | Shows whether tampering is rejected by decryption or reported after the fact. |
| Evidence outputs | Evidence Ledger, Payload Footprint Map, Recovery Runbook, JSON export | Turns the result into something you can audit, compare, or hand off. |
The page also exposes a "security posture" label that summarizes the current risk level. It leans toward hardened when you choose AES-GCM, envelope packaging, stronger KDF cost, and a stronger password; it moves toward compatibility risk when you pick older ciphers, metadata-light output, or weaker KDF settings.
No app backend is involved in the file processing path. The package reads the selected file in the browser, derives keys there, and creates downloadable output from the same session.
For decryption, the main discipline is matching the original parameters. If the incoming payload is raw rather than self-contained, the password alone is not enough; salt, algorithm, padding, encoding, and any AAD must also line up.
The summary badges tell you how the package judges the current setup. A hardened posture usually means authenticated encryption, stronger KDF cost, and a self-contained package. A balanced posture means acceptable but not ideal settings. Compatibility risk means you are leaning on older ciphers, weaker KDF cost, or metadata-light packaging that raises recovery and tamper risk.
The Evidence Ledger is the most important tab for auditing. It records the mode, format, algorithm label, KDF label, KDF parameters, IV or nonce, salt, AAD length, tag length when present, input and output sizes, timestamps, and source host when a payload was decrypted. The JSON export mirrors that view in a structured form for ticketing and reproducibility.
| Result area | What it tells you | What to do with it |
|---|---|---|
| Security posture | A quick risk summary of algorithm, packaging, KDF cost, password strength, and integrity coverage. | Use it to spot weak defaults before you share the output. |
| Integrity label | Shows built-in auth tags for AES-GCM, HMAC sidecar status, or HMAC verification outcome after decryption. | Treat an HMAC failure as untrusted output and re-check the source material before keeping the result. |
| Payload Footprint Map | Breaks the output into bytes contributed by plaintext, ciphertext, IV or nonce, salt, AAD, auth tag, and final download size. | Helpful when you need to explain why one packaging choice is larger than another. |
| Recovery Runbook | Lists concrete hardening or documentation steps based on the current settings. | Use it as a pre-share checklist or a post-decrypt sanity check. |
One subtle point matters here: AES-GCM and HMAC do not fail in the same way. With AES-GCM, integrity problems stop decryption. With the optional HMAC sidecar, the page can still show a decrypted output and separately report whether the HMAC matched. That is useful for investigation, but it means users still need to respect the integrity flag.
Choose AES-GCM (256-bit), keep the output on Envelope, use the hardened Argon2id preset, and leave IV and salt blank. The page generates random values, derives the key, encrypts the file, and saves a .stenc bundle that keeps the metadata needed for recovery.
This is the cleanest setup when you want a portable, authenticated package and an audit trail in the Evidence Ledger.
Suppose you receive a Base64 raw ciphertext that stores only IV plus ciphertext, while salt and algorithm were documented elsewhere. To recover it, you load the file, choose the matching algorithm and encoding, enter the correct salt and password, and then decrypt.
The password is necessary but not sufficient. A missing salt, wrong padding, or mismatched AAD can make the result fail even if the passphrase is correct.
If an existing environment expects a Salted__ wrapper, you can switch to an AES-CBC variant and choose either the Base64 or binary Salted__ output. The page then derives key and IV material with PBKDF2 and packages the result with a salt header.
This is useful for compatibility work, but it is still a compromise compared with AES-GCM envelope packaging because the recovery assumptions are stricter and the integrity story is weaker unless you add an HMAC sidecar.
No app backend handles the file contents in this package. The selected file is processed in the browser session and the result is created as a local download.
AES-GCM with envelope packaging, a strong passphrase, and one of the Argon2id presets is the strongest general-purpose path offered here.
Use it when you are working with a non-GCM mode and want a separate integrity signal. AES-GCM already includes an authentication tag, so the extra sidecar is mainly for compatibility-oriented workflows.
In the non-AEAD paths, decryption and HMAC verification are separate steps. The page can therefore show the recovered bytes and then report whether the HMAC matched. If the HMAC fails, treat the output as untrusted.
Sometimes, but only when the payload and assumptions line up with the AES-CBC and PBKDF2 path used here. Matching password, padding, and iteration choices still matter.
Large files depend on available memory, AES-GCM needs a secure browser context, and raw outputs are easy to strand if you lose the side metadata required for recovery.