Decrypt rijndael-128 String with PHP openssl
To replace mcrypt with openssl I have the following task:
The actual code for encryption and decryption is something like
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key,$plaintext, MCRYPT_MODE_CBC, $iv);
and
$result_decrypt = mcrypt_decrypt(
'rijndael-128',
$key,
$ciphertext,
'cbc',
$iv
);
Works fine, all things are good. Now I want to decrypt the $ciphertext with openssl, I look at MCrypt rijndael-128 to OpenSSL aes-128-ecb conversion and try
function decrypt_openssl_rijndael($value, $unserialize = true, $salt)
{
if (!extension_loaded('openssl')) {
throw new RuntimeException(
'SSL extension is not available.'
);
}
$decrypted = openssl_decrypt($value, 'aes-128-ecb', $salt, OPENSSL_RAW_DATA );
if ($unserialize) {
return unserialize($decrypted);
} else {
return $decrypted;
}
}
I test several options, but I got no properly decrypted string. I suppose I just missed one little thing, so if someone has an idea?
Regards
Thomas
php mcrypt
add a comment |
To replace mcrypt with openssl I have the following task:
The actual code for encryption and decryption is something like
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key,$plaintext, MCRYPT_MODE_CBC, $iv);
and
$result_decrypt = mcrypt_decrypt(
'rijndael-128',
$key,
$ciphertext,
'cbc',
$iv
);
Works fine, all things are good. Now I want to decrypt the $ciphertext with openssl, I look at MCrypt rijndael-128 to OpenSSL aes-128-ecb conversion and try
function decrypt_openssl_rijndael($value, $unserialize = true, $salt)
{
if (!extension_loaded('openssl')) {
throw new RuntimeException(
'SSL extension is not available.'
);
}
$decrypted = openssl_decrypt($value, 'aes-128-ecb', $salt, OPENSSL_RAW_DATA );
if ($unserialize) {
return unserialize($decrypted);
} else {
return $decrypted;
}
}
I test several options, but I got no properly decrypted string. I suppose I just missed one little thing, so if someone has an idea?
Regards
Thomas
php mcrypt
Here's something interesting. Useaes-256-ecb
instead of the 128 one. Blocks sizes are a thing.
– Andrei
Nov 15 '18 at 10:39
1
NNNNNOOOOOO!!!!!!!!! Longer keys are harder to break by brute force, but AES128 already requires the energy and computing resources that not even SciFi can imagine to brute force. OTOH, there other ways to break cryptography. And in the case of AES, longer blocks / keys are more vulnerable than shorter ones to the attacks currently known: schneier.com/blog/archives/2009/07/another_new_aes.html
– symcbean
Nov 15 '18 at 13:05
Hi stackoverflow.com/users/4729332/andrei i have testet this option, but without success.
– Bueck0815
Nov 15 '18 at 13:10
add a comment |
To replace mcrypt with openssl I have the following task:
The actual code for encryption and decryption is something like
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key,$plaintext, MCRYPT_MODE_CBC, $iv);
and
$result_decrypt = mcrypt_decrypt(
'rijndael-128',
$key,
$ciphertext,
'cbc',
$iv
);
Works fine, all things are good. Now I want to decrypt the $ciphertext with openssl, I look at MCrypt rijndael-128 to OpenSSL aes-128-ecb conversion and try
function decrypt_openssl_rijndael($value, $unserialize = true, $salt)
{
if (!extension_loaded('openssl')) {
throw new RuntimeException(
'SSL extension is not available.'
);
}
$decrypted = openssl_decrypt($value, 'aes-128-ecb', $salt, OPENSSL_RAW_DATA );
if ($unserialize) {
return unserialize($decrypted);
} else {
return $decrypted;
}
}
I test several options, but I got no properly decrypted string. I suppose I just missed one little thing, so if someone has an idea?
Regards
Thomas
php mcrypt
To replace mcrypt with openssl I have the following task:
The actual code for encryption and decryption is something like
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_128, MCRYPT_MODE_CBC);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key,$plaintext, MCRYPT_MODE_CBC, $iv);
and
$result_decrypt = mcrypt_decrypt(
'rijndael-128',
$key,
$ciphertext,
'cbc',
$iv
);
Works fine, all things are good. Now I want to decrypt the $ciphertext with openssl, I look at MCrypt rijndael-128 to OpenSSL aes-128-ecb conversion and try
function decrypt_openssl_rijndael($value, $unserialize = true, $salt)
{
if (!extension_loaded('openssl')) {
throw new RuntimeException(
'SSL extension is not available.'
);
}
$decrypted = openssl_decrypt($value, 'aes-128-ecb', $salt, OPENSSL_RAW_DATA );
if ($unserialize) {
return unserialize($decrypted);
} else {
return $decrypted;
}
}
I test several options, but I got no properly decrypted string. I suppose I just missed one little thing, so if someone has an idea?
Regards
Thomas
php mcrypt
php mcrypt
edited Nov 15 '18 at 10:55
jerry
517
517
asked Nov 15 '18 at 10:26
Bueck0815Bueck0815
816
816
Here's something interesting. Useaes-256-ecb
instead of the 128 one. Blocks sizes are a thing.
– Andrei
Nov 15 '18 at 10:39
1
NNNNNOOOOOO!!!!!!!!! Longer keys are harder to break by brute force, but AES128 already requires the energy and computing resources that not even SciFi can imagine to brute force. OTOH, there other ways to break cryptography. And in the case of AES, longer blocks / keys are more vulnerable than shorter ones to the attacks currently known: schneier.com/blog/archives/2009/07/another_new_aes.html
– symcbean
Nov 15 '18 at 13:05
Hi stackoverflow.com/users/4729332/andrei i have testet this option, but without success.
– Bueck0815
Nov 15 '18 at 13:10
add a comment |
Here's something interesting. Useaes-256-ecb
instead of the 128 one. Blocks sizes are a thing.
– Andrei
Nov 15 '18 at 10:39
1
NNNNNOOOOOO!!!!!!!!! Longer keys are harder to break by brute force, but AES128 already requires the energy and computing resources that not even SciFi can imagine to brute force. OTOH, there other ways to break cryptography. And in the case of AES, longer blocks / keys are more vulnerable than shorter ones to the attacks currently known: schneier.com/blog/archives/2009/07/another_new_aes.html
– symcbean
Nov 15 '18 at 13:05
Hi stackoverflow.com/users/4729332/andrei i have testet this option, but without success.
– Bueck0815
Nov 15 '18 at 13:10
Here's something interesting. Use
aes-256-ecb
instead of the 128 one. Blocks sizes are a thing.– Andrei
Nov 15 '18 at 10:39
Here's something interesting. Use
aes-256-ecb
instead of the 128 one. Blocks sizes are a thing.– Andrei
Nov 15 '18 at 10:39
1
1
NNNNNOOOOOO!!!!!!!!! Longer keys are harder to break by brute force, but AES128 already requires the energy and computing resources that not even SciFi can imagine to brute force. OTOH, there other ways to break cryptography. And in the case of AES, longer blocks / keys are more vulnerable than shorter ones to the attacks currently known: schneier.com/blog/archives/2009/07/another_new_aes.html
– symcbean
Nov 15 '18 at 13:05
NNNNNOOOOOO!!!!!!!!! Longer keys are harder to break by brute force, but AES128 already requires the energy and computing resources that not even SciFi can imagine to brute force. OTOH, there other ways to break cryptography. And in the case of AES, longer blocks / keys are more vulnerable than shorter ones to the attacks currently known: schneier.com/blog/archives/2009/07/another_new_aes.html
– symcbean
Nov 15 '18 at 13:05
Hi stackoverflow.com/users/4729332/andrei i have testet this option, but without success.
– Bueck0815
Nov 15 '18 at 13:10
Hi stackoverflow.com/users/4729332/andrei i have testet this option, but without success.
– Bueck0815
Nov 15 '18 at 13:10
add a comment |
1 Answer
1
active
oldest
votes
This should be a comment - but its a bit long.
You are dealing with a very specific issue - in order to solve some greater problem. Normally questions which are as specific as this are welcomed on StackOverflow, however a consequence of this is that the approach often conceals better ways to address the greater problem. This looks like one of those.
Firstly, OpenSSL applies some transformations to the supplied key for encrypt and decrypt operations to make it harder to break the encryption. This is quite common with encryption tools. It is possible that mcrypt does (did) similar, although I suspect it probably doesn't. So you could be using the same key and the same algorithm but get different results. The post you linked to says it works with 256bit blocks. I am dubious, and you seem to have found the same.
You wouldn't want to decrypt data unless it had been encrypted. Where and how it is being encrypted was presumably compatible with mcrypt. A really important question you need to ask is whether your post-mcrypt implementation also needs to compatible with the encryptor / if the ciphertext can be migrated / if the encryptor can be changed.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53317316%2fdecrypt-rijndael-128-string-with-php-openssl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This should be a comment - but its a bit long.
You are dealing with a very specific issue - in order to solve some greater problem. Normally questions which are as specific as this are welcomed on StackOverflow, however a consequence of this is that the approach often conceals better ways to address the greater problem. This looks like one of those.
Firstly, OpenSSL applies some transformations to the supplied key for encrypt and decrypt operations to make it harder to break the encryption. This is quite common with encryption tools. It is possible that mcrypt does (did) similar, although I suspect it probably doesn't. So you could be using the same key and the same algorithm but get different results. The post you linked to says it works with 256bit blocks. I am dubious, and you seem to have found the same.
You wouldn't want to decrypt data unless it had been encrypted. Where and how it is being encrypted was presumably compatible with mcrypt. A really important question you need to ask is whether your post-mcrypt implementation also needs to compatible with the encryptor / if the ciphertext can be migrated / if the encryptor can be changed.
add a comment |
This should be a comment - but its a bit long.
You are dealing with a very specific issue - in order to solve some greater problem. Normally questions which are as specific as this are welcomed on StackOverflow, however a consequence of this is that the approach often conceals better ways to address the greater problem. This looks like one of those.
Firstly, OpenSSL applies some transformations to the supplied key for encrypt and decrypt operations to make it harder to break the encryption. This is quite common with encryption tools. It is possible that mcrypt does (did) similar, although I suspect it probably doesn't. So you could be using the same key and the same algorithm but get different results. The post you linked to says it works with 256bit blocks. I am dubious, and you seem to have found the same.
You wouldn't want to decrypt data unless it had been encrypted. Where and how it is being encrypted was presumably compatible with mcrypt. A really important question you need to ask is whether your post-mcrypt implementation also needs to compatible with the encryptor / if the ciphertext can be migrated / if the encryptor can be changed.
add a comment |
This should be a comment - but its a bit long.
You are dealing with a very specific issue - in order to solve some greater problem. Normally questions which are as specific as this are welcomed on StackOverflow, however a consequence of this is that the approach often conceals better ways to address the greater problem. This looks like one of those.
Firstly, OpenSSL applies some transformations to the supplied key for encrypt and decrypt operations to make it harder to break the encryption. This is quite common with encryption tools. It is possible that mcrypt does (did) similar, although I suspect it probably doesn't. So you could be using the same key and the same algorithm but get different results. The post you linked to says it works with 256bit blocks. I am dubious, and you seem to have found the same.
You wouldn't want to decrypt data unless it had been encrypted. Where and how it is being encrypted was presumably compatible with mcrypt. A really important question you need to ask is whether your post-mcrypt implementation also needs to compatible with the encryptor / if the ciphertext can be migrated / if the encryptor can be changed.
This should be a comment - but its a bit long.
You are dealing with a very specific issue - in order to solve some greater problem. Normally questions which are as specific as this are welcomed on StackOverflow, however a consequence of this is that the approach often conceals better ways to address the greater problem. This looks like one of those.
Firstly, OpenSSL applies some transformations to the supplied key for encrypt and decrypt operations to make it harder to break the encryption. This is quite common with encryption tools. It is possible that mcrypt does (did) similar, although I suspect it probably doesn't. So you could be using the same key and the same algorithm but get different results. The post you linked to says it works with 256bit blocks. I am dubious, and you seem to have found the same.
You wouldn't want to decrypt data unless it had been encrypted. Where and how it is being encrypted was presumably compatible with mcrypt. A really important question you need to ask is whether your post-mcrypt implementation also needs to compatible with the encryptor / if the ciphertext can be migrated / if the encryptor can be changed.
answered Nov 15 '18 at 13:22
symcbeansymcbean
41.2k54076
41.2k54076
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53317316%2fdecrypt-rijndael-128-string-with-php-openssl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Here's something interesting. Use
aes-256-ecb
instead of the 128 one. Blocks sizes are a thing.– Andrei
Nov 15 '18 at 10:39
1
NNNNNOOOOOO!!!!!!!!! Longer keys are harder to break by brute force, but AES128 already requires the energy and computing resources that not even SciFi can imagine to brute force. OTOH, there other ways to break cryptography. And in the case of AES, longer blocks / keys are more vulnerable than shorter ones to the attacks currently known: schneier.com/blog/archives/2009/07/another_new_aes.html
– symcbean
Nov 15 '18 at 13:05
Hi stackoverflow.com/users/4729332/andrei i have testet this option, but without success.
– Bueck0815
Nov 15 '18 at 13:10