{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}

Local file encryption and recovery controls
Choose whether to protect a local file or recover one previously saved as a .stenc envelope.
Drop, browse, or restore the harmless generated sample. Extra files are ignored.
{{ sourceSizeLabel }}
{{ sourceStatus }}
Use a long, unique passphrase and transfer it separately from the encrypted file. No sample passphrase is prefilled.
{{ showPassphrase ? 'Passphrase is visible.' : 'Passphrase is hidden.' }}
AES-GCM 256-bit is the default. The AES-CBC + HMAC option preserves authentication where WebCrypto is unavailable.
Decrypt reads this choice and its cost settings from the protected envelope.
{{ workflowFeedback }}
{{ handoffAnnouncement }}
Use a short non-secret context label only when the receiving workflow requires one.

{{ resultName }}

{{ resultSizeLabel }} · {{ resultDigestLabel }}

FieldValueCopy
{{ row.label }}{{ row.value }}
StepActionCopy
{{ 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

Authenticated file transformation stages
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.

File encryption cipher and key-derivation rules
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 .stenc envelope 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: