Mixing
Why can't decrypt with OpenSSL if salt changed (for CBC and ECB)
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
A file encrypted with OpenSSL (with, for example, AES 256-bit mode CBC) using the Linux command
openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password
has a salt in the first 16 bytes — with the bytes 8-15 being the salt itself. When the file is decrypted, if the salt is modified, OpenSSL will throw a
bad decrypt 140338977786624:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:520:
error, while if the file was encrypted in mode CFB doesn't give you that error.
Why does this happen? What is different about CFB so that it does not produce an error when the salt is modified, compared to the other blockcipher modes of encryption which bluntly fail? Has it something to do with the padding (CBC and ECB do use padding)?
Here's an example of what I'm trying to do: With dd, just one byte is changed in the salt. When trying to decrypt, openssl with throw the error.
echo 'spam' > food.txt
openssl enc -aes-256-cbc -in food.txt -out food.enc -k IDONTLIKENOSPAM!
printf '?' | dd of=food.enc bs=1 seek=12 count=1 conv=notrunc &> /dev/null
openssl enc -d -aes-256-cbc -in food.enc -out food.bad -k IDONTLIKENOSPAM!
cbc openssl salt aes256
edited 2 mins ago
e-sushi♦
13.3k860165
asked 4 hours ago
Sean Walsh
86
New contributor
Sean Walsh is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
favorite
A file encrypted with OpenSSL (with, for example, AES 256-bit mode CBC) using the Linux command
openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password
has a salt in the first 16 bytes — with the bytes 8-15 being the salt itself. When the file is decrypted, if the salt is modified, OpenSSL will throw a
bad decrypt 140338977786624:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:520:
error, while if the file was encrypted in mode CFB doesn't give you that error.
Why does this happen? What is different about CFB so that it does not produce an error when the salt is modified, compared to the other blockcipher modes of encryption which bluntly fail? Has it something to do with the padding (CBC and ECB do use padding)?
Here's an example of what I'm trying to do: With dd, just one byte is changed in the salt. When trying to decrypt, openssl with throw the error.
echo 'spam' > food.txt
openssl enc -aes-256-cbc -in food.txt -out food.enc -k IDONTLIKENOSPAM!
printf '?' | dd of=food.enc bs=1 seek=12 count=1 conv=notrunc &> /dev/null
openssl enc -d -aes-256-cbc -in food.enc -out food.bad -k IDONTLIKENOSPAM!
cbc openssl salt aes256
edited 2 mins ago
e-sushi♦
13.3k860165
asked 4 hours ago
Sean Walsh
86
New contributor
Sean Walsh is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Chances are indeed that the padding is to blame, given that the last block will essentially decrypt to gibberish, you won't get the e.g.03 03 03sequences the padding mandates.
– SEJPM♦
2 hours ago
1
I could be wrong, but padding shouldn't be a problem, since the salt has nothing to do with it.
– Sean Walsh
2 hours ago
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
A file encrypted with OpenSSL (with, for example, AES 256-bit mode CBC) using the Linux command
openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password
has a salt in the first 16 bytes — with the bytes 8-15 being the salt itself. When the file is decrypted, if the salt is modified, OpenSSL will throw a
bad decrypt 140338977786624:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:520:
error, while if the file was encrypted in mode CFB doesn't give you that error.
Why does this happen? What is different about CFB so that it does not produce an error when the salt is modified, compared to the other blockcipher modes of encryption which bluntly fail? Has it something to do with the padding (CBC and ECB do use padding)?
Here's an example of what I'm trying to do: With dd, just one byte is changed in the salt. When trying to decrypt, openssl with throw the error.
echo 'spam' > food.txt
openssl enc -aes-256-cbc -in food.txt -out food.enc -k IDONTLIKENOSPAM!
printf '?' | dd of=food.enc bs=1 seek=12 count=1 conv=notrunc &> /dev/null
openssl enc -d -aes-256-cbc -in food.enc -out food.bad -k IDONTLIKENOSPAM!
cbc openssl salt aes256
edited 2 mins ago
e-sushi♦
13.3k860165
asked 4 hours ago
Sean Walsh
86
New contributor
Sean Walsh is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
A file encrypted with OpenSSL (with, for example, AES 256-bit mode CBC) using the Linux command
openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password
has a salt in the first 16 bytes — with the bytes 8-15 being the salt itself. When the file is decrypted, if the salt is modified, OpenSSL will throw a
bad decrypt 140338977786624:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:520:
error, while if the file was encrypted in mode CFB doesn't give you that error.
Why does this happen? What is different about CFB so that it does not produce an error when the salt is modified, compared to the other blockcipher modes of encryption which bluntly fail? Has it something to do with the padding (CBC and ECB do use padding)?
Here's an example of what I'm trying to do: With dd, just one byte is changed in the salt. When trying to decrypt, openssl with throw the error.
echo 'spam' > food.txt
openssl enc -aes-256-cbc -in food.txt -out food.enc -k IDONTLIKENOSPAM!
printf '?' | dd of=food.enc bs=1 seek=12 count=1 conv=notrunc &> /dev/null
openssl enc -d -aes-256-cbc -in food.enc -out food.bad -k IDONTLIKENOSPAM!
cbc openssl salt aes256
cbc openssl salt aes256
edited 2 mins ago
e-sushi♦
13.3k860165
asked 4 hours ago
Sean Walsh
86
New contributor
Sean Walsh is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 2 mins ago
e-sushi♦
13.3k860165
asked 4 hours ago
Sean Walsh
86
New contributor
Sean Walsh is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 2 mins ago
e-sushi♦
13.3k860165
edited 2 mins ago
e-sushi♦
13.3k860165
edited 2 mins ago
e-sushi♦
13.3k860165
13.3k860165
asked 4 hours ago
Sean Walsh
86
New contributor
Sean Walsh is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 4 hours ago
Sean Walsh
86
asked 4 hours ago
Sean Walsh
86
86
New contributor
Sean Walsh is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Sean Walsh is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Sean Walsh is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Chances are indeed that the padding is to blame, given that the last block will essentially decrypt to gibberish, you won't get the e.g.03 03 03sequences the padding mandates.
– SEJPM♦
2 hours ago
1
I could be wrong, but padding shouldn't be a problem, since the salt has nothing to do with it.
– Sean Walsh
2 hours ago
add a comment |Â
1
Chances are indeed that the padding is to blame, given that the last block will essentially decrypt to gibberish, you won't get the e.g.03 03 03sequences the padding mandates.
– SEJPM♦
2 hours ago
1
I could be wrong, but padding shouldn't be a problem, since the salt has nothing to do with it.
– Sean Walsh
2 hours ago
1
1
Chances are indeed that the padding is to blame, given that the last block will essentially decrypt to gibberish, you won't get the e.g.
03 03 03 sequences the padding mandates.– SEJPM♦
2 hours ago
Chances are indeed that the padding is to blame, given that the last block will essentially decrypt to gibberish, you won't get the e.g.
03 03 03 sequences the padding mandates.– SEJPM♦
2 hours ago
1
1
I could be wrong, but padding shouldn't be a problem, since the salt has nothing to do with it.
– Sean Walsh
2 hours ago
I could be wrong, but padding shouldn't be a problem, since the salt has nothing to do with it.
– Sean Walsh
2 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
In your command:
openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password
a password is supplied, which will be used to derive the key and IV for encryption. The salt stored in the file is used in conjunction with your password for this purpose. Therefore when you change the salt, you will get both a different IV and a different key in the decryption process, not just the IV. Then you will get problem decrypting in block modes such as CBC and ECB because the padding in the decrypted plaintext will not be correct (decrypted with a wrong key). While in stream modes like CFB, there is no padding, so modifying the salt won't cause a problem, but you will get wrong plaintext back.
Edit to add: the EVP_BytesToKey() function is used to turn the password and salt into the key and the IV.
answered 1 hour ago
Changyu Dong
2,553712
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
In your command:
openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password
a password is supplied, which will be used to derive the key and IV for encryption. The salt stored in the file is used in conjunction with your password for this purpose. Therefore when you change the salt, you will get both a different IV and a different key in the decryption process, not just the IV. Then you will get problem decrypting in block modes such as CBC and ECB because the padding in the decrypted plaintext will not be correct (decrypted with a wrong key). While in stream modes like CFB, there is no padding, so modifying the salt won't cause a problem, but you will get wrong plaintext back.
Edit to add: the EVP_BytesToKey() function is used to turn the password and salt into the key and the IV.
answered 1 hour ago
Changyu Dong
2,553712
add a comment |Â
up vote
2
down vote
accepted
In your command:
openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password
a password is supplied, which will be used to derive the key and IV for encryption. The salt stored in the file is used in conjunction with your password for this purpose. Therefore when you change the salt, you will get both a different IV and a different key in the decryption process, not just the IV. Then you will get problem decrypting in block modes such as CBC and ECB because the padding in the decrypted plaintext will not be correct (decrypted with a wrong key). While in stream modes like CFB, there is no padding, so modifying the salt won't cause a problem, but you will get wrong plaintext back.
Edit to add: the EVP_BytesToKey() function is used to turn the password and salt into the key and the IV.
answered 1 hour ago
Changyu Dong
2,553712
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
In your command:
openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password
a password is supplied, which will be used to derive the key and IV for encryption. The salt stored in the file is used in conjunction with your password for this purpose. Therefore when you change the salt, you will get both a different IV and a different key in the decryption process, not just the IV. Then you will get problem decrypting in block modes such as CBC and ECB because the padding in the decrypted plaintext will not be correct (decrypted with a wrong key). While in stream modes like CFB, there is no padding, so modifying the salt won't cause a problem, but you will get wrong plaintext back.
Edit to add: the EVP_BytesToKey() function is used to turn the password and salt into the key and the IV.
answered 1 hour ago
Changyu Dong
2,553712
In your command:
openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password
a password is supplied, which will be used to derive the key and IV for encryption. The salt stored in the file is used in conjunction with your password for this purpose. Therefore when you change the salt, you will get both a different IV and a different key in the decryption process, not just the IV. Then you will get problem decrypting in block modes such as CBC and ECB because the padding in the decrypted plaintext will not be correct (decrypted with a wrong key). While in stream modes like CFB, there is no padding, so modifying the salt won't cause a problem, but you will get wrong plaintext back.
Edit to add: the EVP_BytesToKey() function is used to turn the password and salt into the key and the IV.
answered 1 hour ago
Changyu Dong
2,553712
edited 1 hour ago
answered 1 hour ago
Changyu Dong
2,553712
answered 1 hour ago
Changyu Dong
2,553712
answered 1 hour ago
Changyu Dong
2,553712
2,553712
add a comment |Â
add a comment |Â
Sean Walsh is a new contributor. Be nice, and check out our Code of Conduct.
Sean Walsh is a new contributor. Be nice, and check out our Code of Conduct.
Sean Walsh is a new contributor. Be nice, and check out our Code of Conduct.
Sean Walsh is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f62766%2fwhy-cant-decrypt-with-openssl-if-salt-changed-for-cbc-and-ecb%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Chances are indeed that the padding is to blame, given that the last block will essentially decrypt to gibberish, you won't get the e.g.
03 03 03sequences the padding mandates.– SEJPM♦
2 hours ago
1
I could be wrong, but padding shouldn't be a problem, since the salt has nothing to do with it.
– Sean Walsh
2 hours ago