How openssl padding for AES cfb IV?

Question

From a few documents I have read and a few questions about padding here, I think if I passed a encrypted text fewer than BLOCK SIZE, openssl would pad it per PKCS7. And use that padded encrypted text as IV for next data block.

But when I followed the example (changed method to cfb), I noticed that in decrypt, ctx->iv after EVP_DecryptUpdate was the last part of ciphertext padded in the way I could not figure out.

ciphered text (hex): db 11 d7 9c a8 f2 1c 29 07 dc 6d 62 13 7a 5e bf 3a c2 fa 2f a1 0f 73 90 ae bd cf 57 cf 1f 82 a2 24 ac d1 de 29 6a e2 95 9c 0f ec
IV after decrypt (hex): 24 ac d1 de 29 6a e2 95 9c 0f ec 9a 95 f0 e3 14

So where does "9a 95 f0 e3 14" come from?

Answer 1

Cipher Feedback mode turns the block cipher (AES) into a self-synchronizing stream cipher which feeds back the full ciphertext block as the next IV.

If you encrypt something smaller than a multiple of the block size, it will not use all of the block cipher output to create the ciphertext, just the amount it needs. Therefore there is not a padding requirement either. However it still needs the full output of the block cipher to "feed back" and create more stream output.

In your case, the ciphertext blocks are:

db 11 d7 9c a8 f2 1c 29 07 dc 6d 62 13 7a 5e bf 
3a c2 fa 2f a1 0f 73 90 ae bd cf 57 cf 1f 82 a2
24 ac d1 de 29 6a e2 95 9c 0f ec

As you can see, the last one was truncated after 0xEC, since it did not need it. The remaining 5 bytes of the block cipher output stream are the final 5 bytes of your next IV. In reality if you decide to encrypt more data using the same stream, those 5 bytes will be XORed against the plaintext to create ciphertext, which will change them prior to feedback into the block cipher.

CFB, OFB and CTR modes are stream cipher modes, and therefore do not require padding. There is nothing stopping you from forcing padding, but unlike ECB/CBC modes, you don't need it for data that is not a multiple of the block size.