2
$\begingroup$

Algorithm: AES - CBC mode with PKCS7 padding

KeyValue:

10a58869d74be5a374cf867cfb473859

IV:

00000000000000000000000000000000

Plaintext:

00000000000000000000000000000000

Expected ciphertext:

6d251e6944b051e04eaa6fb4dbf78465

Three steps are used to compute the CBC Encrypt as mentioned below:

CBC_Start(Key,IV)
CBC_Update(Plaintext, plaintext length, Ciphertext, Ciphertextlength)
CBC_Finish(Ciphertext, Ciphertextlength)

Ciphertext is obtained when the update is finished, but when finish is completed, the ciphertext obtained is different from what is expected.

Why is this happening?

|improve this question
$\endgroup$

closed as off-topic by e-sushi Mar 30 '18 at 15:08

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Programming questions are off-topic even if you are writing or debugging cryptographic code. Unless your question is specifically about how the cryptographic algorithm, protocol or side-channel (mitigation) works, you should look into asking on Stack Overflow instead." – e-sushi
If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ It looks like you are trying to use some specific crypto-library. Could you tell us which one? $\endgroup$ – Paŭlo Ebermann Mar 30 '18 at 9:17
  • $\begingroup$ APIs that use the init,update,finish model require that the calls use output buffers that do not overlap and in particular are not exactly the same. The method for doing this varies (wildly) depending on the language you are using, which you didn't state and anyway is offtopic as noted. $\endgroup$ – dave_thompson_085 Mar 31 '18 at 4:28
4
$\begingroup$

Your expected ciphertext is correct if you work with no padding. With PKCS padding the result is 6D251E6944B051E04EAA6FB4DBF78465881572C3A96A612C111055707BD7614E

|improve this answer
$\endgroup$
  • $\begingroup$ Thanks for your reply. Could you pls attach the link of AES CBC with PKCS padding test vectors $\endgroup$ – danny Mar 30 '18 at 9:51
  • $\begingroup$ I have computed the given result with CryptoStuff and CryptoBench $\endgroup$ – gammatester Mar 30 '18 at 11:03
2
$\begingroup$

As gammatester said, the ciphertext you're expecting is correct if you don't use any padding. When using a padding, if you try to encrypt a 16 bytes long message, it will append a full block of padding to your plaintext before the encryption start. Basically, you're encrypting 0000000000000000000000000000000010101010101010101010101010101010 instead of the given plaintext.

|improve this answer
$\endgroup$
  • $\begingroup$ There are couple of questions to clarify : would this padding value 10101010101010101010101010101010 differs based on padding method selected? $\endgroup$ – danny Apr 3 '18 at 4:40
  • $\begingroup$ Here the length of cipher text becomes 32, If i would like to decrypt then what shall i pass the complete CT of size 32 bytes to get the plain text of size 16 bytes? $\endgroup$ – danny Apr 3 '18 at 4:42
  • $\begingroup$ The padding will indeed be different if you use an other padding method. The one I mentioned correspond to PKCS7. If you want to implement AES - CBC mode with PKCS7 padding, you should take care of the padding and the unpadding, so you should give the full ciphertext to the decrypting function (how can you guess how many bytes of padding there is ?) $\endgroup$ – Faulst Apr 3 '18 at 6:38

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