OpenSSL CBC Encrypt corruption of IV
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I'm trying to encrypt "customer" information before writing that information to a file using the OpenSSL CBC-Mode for C.
When I try to encrypt the text it doesn't create an encrypted output it also appears to corrupt the given IV
It goes as follows
BANK: create-user bob 1234 1
PLAINTEXT: bob
IV: 9289437166649966
ENCRYPTION OF NAME OUTPUT:
0010 - <SPACES/NULS> <-- encrypting name outputs nothing
PLAINTEXT: 1234
IV: ��=H�W��I��%%��� <-- IV becomes unusable afterwards
ENCRYPTION OF PIN OUTPUT:
0010 - <SPACES/NULS> <-- Still no encryption output
The corrupted IV is always the same regardless of inputted IV
My code for generating the encryption is this:
unsigned char *cipher_name, *cipher_pin, IV[16], *IV_cpy*plaintext_n, *plaintext_p;
cipher_name = (unsigned char *) calloc(1000, sizeof(unsigned char));
cipher_pin = (unsigned char *) calloc(1000, sizeof(unsigned char));
plaintext_n = (unsigned char *) calloc(1000, sizeof(unsigned char));
plaintext_p = (unsigned char *) calloc(1000, sizeof(unsigned char));
int cipher_len;
.
.
.
rand_gen(IV);
IV_cpy = (unsigned char *)malloc(strlen((char *)IV));
memcpy(IV_cpy, IV, strlen((char *)(IV)));
strcpy((char *)plaintext_n,cmd[1]);
cipher_len = encrypt(plaintext_n, strlen((char *) plaintext_n), IV,cipher_name);
BIO_dump_fp (stdout, (const char *)cipher_name, cipher_len);
strcpy((char *)plaintext_p, cmd[2]);
memcpy(IV_cpy, IV, strlen((char *)(IV)));
cipher_len = encrypt(plaintext_p, strlen((char *) plaintext_p), IV, cipher_pin);
BIO_dump_fp (stdout, (const char *)cipher_pin, cipher_len);
I omitted the print statements to help readability.
The code that generates the IV is:
void rand_gen(unsigned char *ret_val) {
int i, random;
char rand_int[2];
ret_val[0] = '';
srand(time(0));
for(i = 0; i < 16; i++) {
random = rand() % 10;
if(random == 0) {
random = 1;
}
sprintf(rand_int, "%d", random);
strcat((char *)ret_val, rand_int);
}
}
The code for the encrypt function is
int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char
*ciphertext, unsigned char *IV) {
EVP_CIPHER_CTX *ctx;
int len;
int ciphertext_len;
if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();
if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, IV)) handleErrors();
if(1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len)) handleErrors();
ciphertext_len = len;
if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) handleErrors();
ciphertext_len += len;
EVP_CIPHER_CTX_free(ctx);
return ciphertext_len;
}
The key is available elsewhere which is why it's not in the function args
What is being output by encrypt:
0010 - <SPACES/NULS>
What encrypt is supposed to be outputting:
0000 - c7 2b 0a 46 7f 8e 2f e1-7d e6 a3 20 99 c2 7d 2b .+.F../.}.. ..}+
c encryption openssl
|
show 18 more comments
I'm trying to encrypt "customer" information before writing that information to a file using the OpenSSL CBC-Mode for C.
When I try to encrypt the text it doesn't create an encrypted output it also appears to corrupt the given IV
It goes as follows
BANK: create-user bob 1234 1
PLAINTEXT: bob
IV: 9289437166649966
ENCRYPTION OF NAME OUTPUT:
0010 - <SPACES/NULS> <-- encrypting name outputs nothing
PLAINTEXT: 1234
IV: ��=H�W��I��%%��� <-- IV becomes unusable afterwards
ENCRYPTION OF PIN OUTPUT:
0010 - <SPACES/NULS> <-- Still no encryption output
The corrupted IV is always the same regardless of inputted IV
My code for generating the encryption is this:
unsigned char *cipher_name, *cipher_pin, IV[16], *IV_cpy*plaintext_n, *plaintext_p;
cipher_name = (unsigned char *) calloc(1000, sizeof(unsigned char));
cipher_pin = (unsigned char *) calloc(1000, sizeof(unsigned char));
plaintext_n = (unsigned char *) calloc(1000, sizeof(unsigned char));
plaintext_p = (unsigned char *) calloc(1000, sizeof(unsigned char));
int cipher_len;
.
.
.
rand_gen(IV);
IV_cpy = (unsigned char *)malloc(strlen((char *)IV));
memcpy(IV_cpy, IV, strlen((char *)(IV)));
strcpy((char *)plaintext_n,cmd[1]);
cipher_len = encrypt(plaintext_n, strlen((char *) plaintext_n), IV,cipher_name);
BIO_dump_fp (stdout, (const char *)cipher_name, cipher_len);
strcpy((char *)plaintext_p, cmd[2]);
memcpy(IV_cpy, IV, strlen((char *)(IV)));
cipher_len = encrypt(plaintext_p, strlen((char *) plaintext_p), IV, cipher_pin);
BIO_dump_fp (stdout, (const char *)cipher_pin, cipher_len);
I omitted the print statements to help readability.
The code that generates the IV is:
void rand_gen(unsigned char *ret_val) {
int i, random;
char rand_int[2];
ret_val[0] = '';
srand(time(0));
for(i = 0; i < 16; i++) {
random = rand() % 10;
if(random == 0) {
random = 1;
}
sprintf(rand_int, "%d", random);
strcat((char *)ret_val, rand_int);
}
}
The code for the encrypt function is
int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char
*ciphertext, unsigned char *IV) {
EVP_CIPHER_CTX *ctx;
int len;
int ciphertext_len;
if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();
if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, IV)) handleErrors();
if(1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len)) handleErrors();
ciphertext_len = len;
if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) handleErrors();
ciphertext_len += len;
EVP_CIPHER_CTX_free(ctx);
return ciphertext_len;
}
The key is available elsewhere which is why it's not in the function args
What is being output by encrypt:
0010 - <SPACES/NULS>
What encrypt is supposed to be outputting:
0000 - c7 2b 0a 46 7f 8e 2f e1-7d e6 a3 20 99 c2 7d 2b .+.F../.}.. ..}+
c encryption openssl
Fyi, the IV fed to any of the IV-utilizing algorithms performed by EVP encipherment functions is intentionally updated inline. There'a a reason that buffer isn't addressed byconst unsigned char*
. And fwiw, there are many other ways to generate a random IV than what you're doing (which isn't very random at all).
– WhozCraig
Nov 21 '18 at 23:11
Sorry, a little confused, but should I make a copy of the IV and use that for the second encryption?
– Ronoc Eroom
Nov 21 '18 at 23:22
1
Encrypted data won't necessarily be printable strings (in fact it's highly unlikely). Fire up a debugger and inspect the content of the memory behindcipher_name
andcipher_pin
.
– WhozCraig
Nov 21 '18 at 23:55
1
Worth noting, the output with spaces/null is missing the intentional terminating byte of the plaintext buffer on the prior line (it's actuallychar pt = "0123";
and i'm intentionally using the entire buffer, terminator and all). I just noticed that. how odd. If you can, look at the two side by side. Regardless, I think you're getting your cipher text, regardless of that bizarre output. I tested your function and it seems correct.
– WhozCraig
Nov 22 '18 at 0:34
2
Your arguments are swapped. You call encrypt with (plain_buf, plain_len, IV, cipher_buf) but encrypt's parameters are (plain_buf, plain_len, cipher_buf, IV) so it treats the (zeroed) cipherbuf as the IV and writes the ciphertext to the IV buffer. Since nothing is written to either cipher buffer they dump as all-zeros. Also in your edit you allocate IV_cpy and copy to it, but still use IV in the encrypt calls, so IV_cpy is effectively wasted.
– dave_thompson_085
Nov 22 '18 at 2:44
|
show 18 more comments
I'm trying to encrypt "customer" information before writing that information to a file using the OpenSSL CBC-Mode for C.
When I try to encrypt the text it doesn't create an encrypted output it also appears to corrupt the given IV
It goes as follows
BANK: create-user bob 1234 1
PLAINTEXT: bob
IV: 9289437166649966
ENCRYPTION OF NAME OUTPUT:
0010 - <SPACES/NULS> <-- encrypting name outputs nothing
PLAINTEXT: 1234
IV: ��=H�W��I��%%��� <-- IV becomes unusable afterwards
ENCRYPTION OF PIN OUTPUT:
0010 - <SPACES/NULS> <-- Still no encryption output
The corrupted IV is always the same regardless of inputted IV
My code for generating the encryption is this:
unsigned char *cipher_name, *cipher_pin, IV[16], *IV_cpy*plaintext_n, *plaintext_p;
cipher_name = (unsigned char *) calloc(1000, sizeof(unsigned char));
cipher_pin = (unsigned char *) calloc(1000, sizeof(unsigned char));
plaintext_n = (unsigned char *) calloc(1000, sizeof(unsigned char));
plaintext_p = (unsigned char *) calloc(1000, sizeof(unsigned char));
int cipher_len;
.
.
.
rand_gen(IV);
IV_cpy = (unsigned char *)malloc(strlen((char *)IV));
memcpy(IV_cpy, IV, strlen((char *)(IV)));
strcpy((char *)plaintext_n,cmd[1]);
cipher_len = encrypt(plaintext_n, strlen((char *) plaintext_n), IV,cipher_name);
BIO_dump_fp (stdout, (const char *)cipher_name, cipher_len);
strcpy((char *)plaintext_p, cmd[2]);
memcpy(IV_cpy, IV, strlen((char *)(IV)));
cipher_len = encrypt(plaintext_p, strlen((char *) plaintext_p), IV, cipher_pin);
BIO_dump_fp (stdout, (const char *)cipher_pin, cipher_len);
I omitted the print statements to help readability.
The code that generates the IV is:
void rand_gen(unsigned char *ret_val) {
int i, random;
char rand_int[2];
ret_val[0] = '';
srand(time(0));
for(i = 0; i < 16; i++) {
random = rand() % 10;
if(random == 0) {
random = 1;
}
sprintf(rand_int, "%d", random);
strcat((char *)ret_val, rand_int);
}
}
The code for the encrypt function is
int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char
*ciphertext, unsigned char *IV) {
EVP_CIPHER_CTX *ctx;
int len;
int ciphertext_len;
if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();
if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, IV)) handleErrors();
if(1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len)) handleErrors();
ciphertext_len = len;
if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) handleErrors();
ciphertext_len += len;
EVP_CIPHER_CTX_free(ctx);
return ciphertext_len;
}
The key is available elsewhere which is why it's not in the function args
What is being output by encrypt:
0010 - <SPACES/NULS>
What encrypt is supposed to be outputting:
0000 - c7 2b 0a 46 7f 8e 2f e1-7d e6 a3 20 99 c2 7d 2b .+.F../.}.. ..}+
c encryption openssl
I'm trying to encrypt "customer" information before writing that information to a file using the OpenSSL CBC-Mode for C.
When I try to encrypt the text it doesn't create an encrypted output it also appears to corrupt the given IV
It goes as follows
BANK: create-user bob 1234 1
PLAINTEXT: bob
IV: 9289437166649966
ENCRYPTION OF NAME OUTPUT:
0010 - <SPACES/NULS> <-- encrypting name outputs nothing
PLAINTEXT: 1234
IV: ��=H�W��I��%%��� <-- IV becomes unusable afterwards
ENCRYPTION OF PIN OUTPUT:
0010 - <SPACES/NULS> <-- Still no encryption output
The corrupted IV is always the same regardless of inputted IV
My code for generating the encryption is this:
unsigned char *cipher_name, *cipher_pin, IV[16], *IV_cpy*plaintext_n, *plaintext_p;
cipher_name = (unsigned char *) calloc(1000, sizeof(unsigned char));
cipher_pin = (unsigned char *) calloc(1000, sizeof(unsigned char));
plaintext_n = (unsigned char *) calloc(1000, sizeof(unsigned char));
plaintext_p = (unsigned char *) calloc(1000, sizeof(unsigned char));
int cipher_len;
.
.
.
rand_gen(IV);
IV_cpy = (unsigned char *)malloc(strlen((char *)IV));
memcpy(IV_cpy, IV, strlen((char *)(IV)));
strcpy((char *)plaintext_n,cmd[1]);
cipher_len = encrypt(plaintext_n, strlen((char *) plaintext_n), IV,cipher_name);
BIO_dump_fp (stdout, (const char *)cipher_name, cipher_len);
strcpy((char *)plaintext_p, cmd[2]);
memcpy(IV_cpy, IV, strlen((char *)(IV)));
cipher_len = encrypt(plaintext_p, strlen((char *) plaintext_p), IV, cipher_pin);
BIO_dump_fp (stdout, (const char *)cipher_pin, cipher_len);
I omitted the print statements to help readability.
The code that generates the IV is:
void rand_gen(unsigned char *ret_val) {
int i, random;
char rand_int[2];
ret_val[0] = '';
srand(time(0));
for(i = 0; i < 16; i++) {
random = rand() % 10;
if(random == 0) {
random = 1;
}
sprintf(rand_int, "%d", random);
strcat((char *)ret_val, rand_int);
}
}
The code for the encrypt function is
int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char
*ciphertext, unsigned char *IV) {
EVP_CIPHER_CTX *ctx;
int len;
int ciphertext_len;
if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();
if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, IV)) handleErrors();
if(1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len)) handleErrors();
ciphertext_len = len;
if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) handleErrors();
ciphertext_len += len;
EVP_CIPHER_CTX_free(ctx);
return ciphertext_len;
}
The key is available elsewhere which is why it's not in the function args
What is being output by encrypt:
0010 - <SPACES/NULS>
What encrypt is supposed to be outputting:
0000 - c7 2b 0a 46 7f 8e 2f e1-7d e6 a3 20 99 c2 7d 2b .+.F../.}.. ..}+
c encryption openssl
c encryption openssl
edited Nov 22 '18 at 0:17
Ronoc Eroom
asked Nov 21 '18 at 23:00
Ronoc EroomRonoc Eroom
135
135
Fyi, the IV fed to any of the IV-utilizing algorithms performed by EVP encipherment functions is intentionally updated inline. There'a a reason that buffer isn't addressed byconst unsigned char*
. And fwiw, there are many other ways to generate a random IV than what you're doing (which isn't very random at all).
– WhozCraig
Nov 21 '18 at 23:11
Sorry, a little confused, but should I make a copy of the IV and use that for the second encryption?
– Ronoc Eroom
Nov 21 '18 at 23:22
1
Encrypted data won't necessarily be printable strings (in fact it's highly unlikely). Fire up a debugger and inspect the content of the memory behindcipher_name
andcipher_pin
.
– WhozCraig
Nov 21 '18 at 23:55
1
Worth noting, the output with spaces/null is missing the intentional terminating byte of the plaintext buffer on the prior line (it's actuallychar pt = "0123";
and i'm intentionally using the entire buffer, terminator and all). I just noticed that. how odd. If you can, look at the two side by side. Regardless, I think you're getting your cipher text, regardless of that bizarre output. I tested your function and it seems correct.
– WhozCraig
Nov 22 '18 at 0:34
2
Your arguments are swapped. You call encrypt with (plain_buf, plain_len, IV, cipher_buf) but encrypt's parameters are (plain_buf, plain_len, cipher_buf, IV) so it treats the (zeroed) cipherbuf as the IV and writes the ciphertext to the IV buffer. Since nothing is written to either cipher buffer they dump as all-zeros. Also in your edit you allocate IV_cpy and copy to it, but still use IV in the encrypt calls, so IV_cpy is effectively wasted.
– dave_thompson_085
Nov 22 '18 at 2:44
|
show 18 more comments
Fyi, the IV fed to any of the IV-utilizing algorithms performed by EVP encipherment functions is intentionally updated inline. There'a a reason that buffer isn't addressed byconst unsigned char*
. And fwiw, there are many other ways to generate a random IV than what you're doing (which isn't very random at all).
– WhozCraig
Nov 21 '18 at 23:11
Sorry, a little confused, but should I make a copy of the IV and use that for the second encryption?
– Ronoc Eroom
Nov 21 '18 at 23:22
1
Encrypted data won't necessarily be printable strings (in fact it's highly unlikely). Fire up a debugger and inspect the content of the memory behindcipher_name
andcipher_pin
.
– WhozCraig
Nov 21 '18 at 23:55
1
Worth noting, the output with spaces/null is missing the intentional terminating byte of the plaintext buffer on the prior line (it's actuallychar pt = "0123";
and i'm intentionally using the entire buffer, terminator and all). I just noticed that. how odd. If you can, look at the two side by side. Regardless, I think you're getting your cipher text, regardless of that bizarre output. I tested your function and it seems correct.
– WhozCraig
Nov 22 '18 at 0:34
2
Your arguments are swapped. You call encrypt with (plain_buf, plain_len, IV, cipher_buf) but encrypt's parameters are (plain_buf, plain_len, cipher_buf, IV) so it treats the (zeroed) cipherbuf as the IV and writes the ciphertext to the IV buffer. Since nothing is written to either cipher buffer they dump as all-zeros. Also in your edit you allocate IV_cpy and copy to it, but still use IV in the encrypt calls, so IV_cpy is effectively wasted.
– dave_thompson_085
Nov 22 '18 at 2:44
Fyi, the IV fed to any of the IV-utilizing algorithms performed by EVP encipherment functions is intentionally updated inline. There'a a reason that buffer isn't addressed by
const unsigned char*
. And fwiw, there are many other ways to generate a random IV than what you're doing (which isn't very random at all).– WhozCraig
Nov 21 '18 at 23:11
Fyi, the IV fed to any of the IV-utilizing algorithms performed by EVP encipherment functions is intentionally updated inline. There'a a reason that buffer isn't addressed by
const unsigned char*
. And fwiw, there are many other ways to generate a random IV than what you're doing (which isn't very random at all).– WhozCraig
Nov 21 '18 at 23:11
Sorry, a little confused, but should I make a copy of the IV and use that for the second encryption?
– Ronoc Eroom
Nov 21 '18 at 23:22
Sorry, a little confused, but should I make a copy of the IV and use that for the second encryption?
– Ronoc Eroom
Nov 21 '18 at 23:22
1
1
Encrypted data won't necessarily be printable strings (in fact it's highly unlikely). Fire up a debugger and inspect the content of the memory behind
cipher_name
and cipher_pin
.– WhozCraig
Nov 21 '18 at 23:55
Encrypted data won't necessarily be printable strings (in fact it's highly unlikely). Fire up a debugger and inspect the content of the memory behind
cipher_name
and cipher_pin
.– WhozCraig
Nov 21 '18 at 23:55
1
1
Worth noting, the output with spaces/null is missing the intentional terminating byte of the plaintext buffer on the prior line (it's actually
char pt = "0123";
and i'm intentionally using the entire buffer, terminator and all). I just noticed that. how odd. If you can, look at the two side by side. Regardless, I think you're getting your cipher text, regardless of that bizarre output. I tested your function and it seems correct.– WhozCraig
Nov 22 '18 at 0:34
Worth noting, the output with spaces/null is missing the intentional terminating byte of the plaintext buffer on the prior line (it's actually
char pt = "0123";
and i'm intentionally using the entire buffer, terminator and all). I just noticed that. how odd. If you can, look at the two side by side. Regardless, I think you're getting your cipher text, regardless of that bizarre output. I tested your function and it seems correct.– WhozCraig
Nov 22 '18 at 0:34
2
2
Your arguments are swapped. You call encrypt with (plain_buf, plain_len, IV, cipher_buf) but encrypt's parameters are (plain_buf, plain_len, cipher_buf, IV) so it treats the (zeroed) cipherbuf as the IV and writes the ciphertext to the IV buffer. Since nothing is written to either cipher buffer they dump as all-zeros. Also in your edit you allocate IV_cpy and copy to it, but still use IV in the encrypt calls, so IV_cpy is effectively wasted.
– dave_thompson_085
Nov 22 '18 at 2:44
Your arguments are swapped. You call encrypt with (plain_buf, plain_len, IV, cipher_buf) but encrypt's parameters are (plain_buf, plain_len, cipher_buf, IV) so it treats the (zeroed) cipherbuf as the IV and writes the ciphertext to the IV buffer. Since nothing is written to either cipher buffer they dump as all-zeros. Also in your edit you allocate IV_cpy and copy to it, but still use IV in the encrypt calls, so IV_cpy is effectively wasted.
– dave_thompson_085
Nov 22 '18 at 2:44
|
show 18 more comments
0
active
oldest
votes
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%2f53421649%2fopenssl-cbc-encrypt-corruption-of-iv%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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%2f53421649%2fopenssl-cbc-encrypt-corruption-of-iv%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
Fyi, the IV fed to any of the IV-utilizing algorithms performed by EVP encipherment functions is intentionally updated inline. There'a a reason that buffer isn't addressed by
const unsigned char*
. And fwiw, there are many other ways to generate a random IV than what you're doing (which isn't very random at all).– WhozCraig
Nov 21 '18 at 23:11
Sorry, a little confused, but should I make a copy of the IV and use that for the second encryption?
– Ronoc Eroom
Nov 21 '18 at 23:22
1
Encrypted data won't necessarily be printable strings (in fact it's highly unlikely). Fire up a debugger and inspect the content of the memory behind
cipher_name
andcipher_pin
.– WhozCraig
Nov 21 '18 at 23:55
1
Worth noting, the output with spaces/null is missing the intentional terminating byte of the plaintext buffer on the prior line (it's actually
char pt = "0123";
and i'm intentionally using the entire buffer, terminator and all). I just noticed that. how odd. If you can, look at the two side by side. Regardless, I think you're getting your cipher text, regardless of that bizarre output. I tested your function and it seems correct.– WhozCraig
Nov 22 '18 at 0:34
2
Your arguments are swapped. You call encrypt with (plain_buf, plain_len, IV, cipher_buf) but encrypt's parameters are (plain_buf, plain_len, cipher_buf, IV) so it treats the (zeroed) cipherbuf as the IV and writes the ciphertext to the IV buffer. Since nothing is written to either cipher buffer they dump as all-zeros. Also in your edit you allocate IV_cpy and copy to it, but still use IV in the encrypt calls, so IV_cpy is effectively wasted.
– dave_thompson_085
Nov 22 '18 at 2:44