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;
}







2















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../.}.. ..}+









share|improve this question

























  • 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 and cipher_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


















2















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../.}.. ..}+









share|improve this question

























  • 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 and cipher_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














2












2








2








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../.}.. ..}+









share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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 and cipher_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



















  • 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 and cipher_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

















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












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
});


}
});














draft saved

draft discarded


















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
















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

鏡平學校

ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

Why https connections are so slow when debugging (stepping over) in Java?