Text Encryptor & Decryptor

Introduction:

Encrypted text is readable writing turned into coded characters with a secret that the reader knows, so only the right person can bring it back to plain words. Password based text encryption and decryption helps protect notes, drafts, and snippets you want to keep private or share safely.

Enter your text and a memorable passphrase, then choose whether to protect it or to recover something you received. The result can be a compact self describing envelope for easy sharing, a raw string for pipelines, or a legacy style output for tools that expect a traditional format.

A quick example is saving a meeting summary before sending it to a teammate. Protect it with a strong passphrase, share the encoded output, and they can paste it back with the same passphrase to read it clearly.

Stronger passphrases lead to better protection, and keeping the salt and the initial value when you choose raw output avoids surprises later. If an integrity check reports a mismatch, treat the content as untrusted.

Technical Details:

The object is password protected text, transformed using symmetric ciphers so that one secret unlocks what the same secret created. The observable quantities are ciphertext length, authentication tag length, optional associated data length, and the presence of a message authentication code.

Keys are derived from a passphrase and a per message salt using a key derivation function (KDF). Two KDFs are available: Argon2id and PBKDF2 using Secure Hash Algorithm 256. The transformation encrypts UTF‑8 bytes of the text; authenticated modes attach a verification tag, and envelope packaging can carry a separate Hash‑based Message Authentication Code (HMAC) for integrity.

Results indicate confidentiality and, when present, integrity. Authenticated encryption with associated data (AEAD) uses an authentication tag to detect changes. Envelopes may also include an HMAC; a negative check means the inputs or content do not match and should not be trusted.

Comparability depends on keeping the algorithm, KDF parameters, salt, and initialization vector constant. An envelope records these so another reader can decrypt without guessing. Raw outputs omit those labels and require you to manage the salt and initial value yourself.

Processing pipeline:

1. Normalize text to UTF‑8 bytes.
2. Derive a key from the passphrase and salt using Argon2id or PBKDF2‑SHA256.
3. Create or validate the IV/nonce length for the chosen cipher.
4. Encrypt bytes using the selected algorithm and padding rules.
5. For AEAD, attach a 16‑byte authentication tag; include associated data if provided.
6. For envelopes, compute HMAC‑SHA256 over algorithm, salt, IV, and ciphertext.
7. Package as Envelope JSON, Raw string (IV​||​CT), Raw binary, or OpenSSL Salted output.

Algorithm families & IV sizes:

• AES‑GCM (128, 256) — IV 12 bytes; authenticated encryption with optional associated data.
• AES‑CBC/CTR/CFB/OFB (128, 192, 256) — IV 16 bytes; padding applies to block modes.
• DES‑CBC and TripleDES‑CBC — IV 8 bytes; provided for compatibility.
• RC4 and Rabbit — stream ciphers; RC4 ignores IV; Rabbit uses 8‑byte IV.

KDF options:

• Argon2id — parameters: passes and memory in MB; defaults are 3 passes and 64 MB.
• PBKDF2‑SHA256 — parameter: iterations; default is 210 000; minimum enforced is 10 000.

Units, precision & rounding:

All byte counts are integers. Hex fields use two hex characters per byte. Base 64 uses standard alphabet with optional padding.

Validation & bounds extracted from code:

I/O formats & encoding:

Networking & storage behavior:

Processing is browser‑based. Content is transformed locally, and downloads are created as temporary object URLs. No data is transmitted or stored server‑side.

Diagnostics & determinism:

Given the same algorithm, KDF settings, salt, IV, and text, outputs are deterministic. When salt or IV are created for you, results will differ across runs by design.

Security considerations:

• Use long passphrases; short ones weaken the derived key.
• Prefer authenticated modes or add HMAC for tamper detection.
• Keep salt and IV with the ciphertext when you choose raw output.
• Legacy ciphers are present for compatibility; choose modern modes for new data.

Assumptions & limitations:

• Heads‑up Raw decryption requires the exact salt and IV.
• Heads‑up AES‑GCM uses a fixed 12‑byte IV and a 16‑byte tag.
• Padding applies only to block modes; CTR, RC4, Rabbit, and GCM ignore padding.
• OpenSSL outputs use PBKDF2‑SHA256; choose an AES‑CBC variant to decrypt.
• ZeroPadding and NoPadding demand block‑aligned plaintext for CBC.
• Envelope JSON includes algorithm, KDF params, salt, IV, encoding, and optional HMAC.
• Stream ciphers provide no inherent authentication; consider an envelope with HMAC.
• Text is handled as UTF‑8; binary payloads should be encoded as text first.

Edge cases & error sources:

• Invalid hex (odd length or non‑hex characters) yields an empty byte array.
• Malformed Base 64 fails to decode or decrypt.
• Wrong algorithm selection prevents successful decryption.
• Wrong salt or IV in raw mode makes decryption impossible.
• AAD mismatch in AEAD causes tag verification failure.
• IV length must match the algorithm exactly; RC4 ignores IV entirely.
• NoPadding or ZeroPadding with non‑aligned plaintext breaks CBC semantics.
• OpenSSL decryption fails with non‑CBC algorithms.
• HMAC mismatch indicates corruption or wrong inputs and should not be ignored.
• Very large Argon2 memory values may exhaust device resources.

Scientific/standards backing:

AES and Galois/Counter Mode, PBKDF2 with SHA‑256, Argon2id, and HMAC‑SHA256 are established methods in cryptography standards and academic specifications.

Privacy & compliance:

No data is transmitted or stored server‑side. Handle secrets responsibly and follow applicable privacy regulations for sensitive content.

How‑to Guide:

Password protected text lets you turn readable content into ciphertext and recover it later with the same passphrase.

1. Paste or load your text. Provide a password.
2. Choose Encrypt or Decrypt.
3. Select an algorithm and a KDF.
4. Optionally set salt, IV, and AAD.
5. Pick an output: Envelope, Raw, Raw binary, or OpenSSL.
6. Run the action, then copy or download the result.

Example: Encrypt a note with AES‑GCM and Argon2id. Share the envelope JSON. The recipient pastes the envelope and enters the same password to read it.

Keep the salt and IV with raw outputs to ensure future decryption.

FAQ:

Troubleshooting:

• “Enter text and password.” — Provide both before running.
• “OpenSSL format requires AES‑CBC.” — Switch the algorithm to AES‑CBC.
• “Bad HMAC.” — Password, salt, IV, or content mismatch; do not trust the result.
• GCM tag errors — Confirm AAD, IV length 12 bytes, and password.
• Raw decryption fails — Provide the exact salt and IV used at encryption.
• Invalid hex — Ensure an even number of characters and only 0‑9 a‑f.

Advanced Tips:

• Tip Prefer envelopes for portability; they carry algorithm, KDF parameters, salt, IV, and optional HMAC.
• Tip Use AAD in GCM to bind context such as a filename or note title.
• Tip Keep salt and IV alongside raw outputs to enable future decryption.
• Tip Increase Argon2 memory or PBKDF2 iterations for stronger keys on capable devices.
• Tip For non‑AEAD ciphers, enable HMAC in the envelope to detect tampering.
• Tip When interoperability matters, choose OpenSSL outputs and AES‑CBC with matching parameters.

Glossary:

Ciphertext (CT)

The encoded form of your text after encryption.

Initialization Vector (IV)

A per message value that makes outputs unique.

Salt

Random bytes added to the KDF to diversify keys.

Key Derivation Function (KDF)

Algorithm that turns a passphrase and salt into a key.

Authenticated Encryption (AEAD)

Encryption that adds a tag to detect tampering.

Associated Data (AAD)

Extra context that must match at decryption time.

HMAC‑SHA256

Integrity code computed from key and message bytes.

Envelope

Self describing JSON package of metadata and ciphertext.