Protect & Encrypt · Field note
How to Decrypt Text with OpenSSL
Decrypt OpenSSL enc output by matching its cipher, PBKDF2, digest, salt, and Base64 settings, then verify the recovered bytes.
Before you start
Run the workflow once with a disposable value, then do a decrypt or restore check before you share anything real.
An OpenSSL passphrase is only one part of a successful decrypt. The cipher, password derivation, digest, iteration count, salt handling, and Base64 settings must agree with the original encryption command.
If the command was not recorded, a correct passphrase may still be insufficient.
In brief
Reconstruct the original openssl enc recipe before changing flags at random. Match the cipher and PBKDF2 settings first, then confirm whether the encrypted input is raw binary or Base64 text.
After decryption, compare the recovered bytes with a known value. No error message does not automatically mean the plaintext is authentic or correct.
Collect evidence before retrying
Write down what is known:
- The exact cipher and mode, such as
aes-256-cbc. - Whether encryption used a passphrase or a raw key and IV.
- Whether
-pbkdf2or-iterwas present, plus the iteration count. - The digest supplied with
-md. - Whether the encrypted value was Base64 encoded with
-a, and whether it was written as one line with-A. - Whether the salt was generated normally, disabled with
-nosalt, or supplied explicitly with-S. - The OpenSSL version used to create the data.
The random salt is normally stored at the beginning of the encrypted data. The cipher and PBKDF2 settings are not recovered from that salt, so preserve the original command whenever possible.
Run the matching decrypt command
For output created with the companion recipe in this guide set, use:
openssl enc -d -aes-256-cbc -pbkdf2 -iter 100000 -md sha256 \
-a -A -in message.enc -out message.txt
Remove -A when the Base64 input has normal line wrapping. Remove both -a and -A when the encrypted input is binary. Change the cipher, iteration count, and digest only to match the original encryption settings.
Read errors as clues, not diagnoses
bad decrypt often points to a wrong passphrase or a mismatched cipher, digest, PBKDF2 setting, iteration count, or salt. It can also follow damaged input.
Gibberish without a hard error is possible. CBC padding supplies only a weak check, so incorrect inputs can occasionally produce output that passes the padding step.
Base64 errors are a separate layer. If a copied value is one long line, -a -A tells OpenSSL to decode Base64 without expecting line breaks. Fixing Base64 does not fix a wrong cipher or passphrase.
Handle explicit salts carefully
Avoid adding -S unless the encryption recipe used an explicit salt. If it did, supply the same hexadecimal salt during decryption.
OpenSSL 3.0 changed this behavior: an explicit -S value is no longer prepended during encryption. Data created with an explicit salt under OpenSSL 1.1.1 may therefore need a different decrypt command than data created under OpenSSL 3.0 or later. Check openssl version before copying an old recipe unchanged.
Verify the recovered bytes
A round-trip comparison is the cleanest check when you still have the original:
cmp -s message.original message.txt && echo 'exact match'
openssl dgst -sha256 message.txt
When the original is unavailable, compare against a checksum from a trusted source or a precise expected structure. A familiar-looking first line is a useful clue, not proof that every byte is correct.
Keep browser decrypt formats separate
The Encrypt Online homepage and /decrypt do not implement the PBKDF2 openssl enc recipe in this article. Pasting this ciphertext there will not reproduce the command-line result. Use OpenSSL with the original parameters.
The Base64 Decode tool can help identify wrapping or copy damage, but it only decodes the transport text. It does not decrypt OpenSSL ciphertext.
Questions behind common failures
What if I know only the password?
Try to recover the original command, application documentation, or sender's settings. OpenSSL cannot reliably infer the cipher and password-derivation choices from a normal enc payload.
Should I add -pbkdf2 when an old command did not use it?
No. PBKDF2 is the better choice when creating a new password-based recipe, but decryption must reproduce the method used to create the existing ciphertext. Adding it changes the derived key and IV.
Why did -a work but -a -A was needed after copying the value?
Normal Base64 output contains line breaks. A chat field, environment variable, or clipboard step may collapse it to one line. -A changes OpenSSL's Base64 handling so it does not require those newlines.