0
$\begingroup$

I have a bit problem with padding. Everything goes fine when I encrypt the text BUT when I decrypt I see some extra characters. Sometime's one character sometimes more and I dont know how to remove them.

But one question I am really upset with is that why does padding show in my decrypted text BUT now others?

Here's my code (PHP) to generate IV:

if($iv = openssl_random_pseudo_bytes(32)){
        $final_iv = substr(base64_encode($iv), 0, 32);
    //The IV size should be 32 characters
}

Here's example of the paddings:

E¢9Àšæ—–Í

Qcn«ûØ›§Ñ¼waf—®

º„%¬â;¸*Í”¨Ö
$\endgroup$

closed as unclear what you're asking by Ilmari Karonen, yyyyyyy, Henrick Hellström, DrLecter, cygnusv Mar 12 '15 at 10:42

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ The IV generation code makes no sense. 32 Base64 characters would correspond to a cipher with 192 bit blocks, which is highly unusual. $\endgroup$ – CodesInChaos Feb 9 '15 at 11:34
1
$\begingroup$

First, you have to know what padding you are using. In the padding, you will find the padding length.

Second, you should set the padding type in the library.

Third, removing and validating and using padding is tricky and can lead to some padding oracle attacks. In essential, the attacker modifies a block, which is likely to result in wrong padding and a wrong message, but it might also result in a correct message. Attacker then observes if the message was accepted or not and makes some deduction.

To mitigate the padding oracle attack, the easiest way is using encrypt-then-MAC. As a result, any modified message is rejected and attacker can't observe differences between two garbled messages. (Probability of accepting a garbled message is negligible.)

These padding oracle attacks aren't theoretical. For example, SSL3 was killed by one of padding oracle attacks, i.e. POODLE.

$\endgroup$
  • $\begingroup$ Not all padding includes a padding length, PHP mcrypt only supplies null padding. $\endgroup$ – zaph Feb 26 '16 at 14:07
  • $\begingroup$ OK, we can consider mcrypt as an exception. I consider mcrypt to be a punk and I am not sure if it is even maintained now. $\endgroup$ – v6ak Feb 26 '16 at 19:16
  • $\begingroup$ Hasn't been maintained for years but is unfortunately heavily used. $\endgroup$ – zaph Feb 26 '16 at 19:21
1
$\begingroup$

It would really help to see the encryption and decryption code, as used by your program.

The Handling of the IV does not seem right. The IV has the size of the block of the cipher used in conjunction with CBC. Thus it should probably be 16 bytes in length. Additionally you have to use the RAW bytes for CBC and not its Base64 representation.

In order to transmit IV and cipher text, you may apply a Base64 encoding if necessary. But do not cut parts away, as otherwise you will never be able to decrypt your data again.

Finally, an ASCII representation of encrypted data does not help much. Please provide any data as hex-codes (e.g. 01 FE AB 9F etc).

$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.