2
$\begingroup$

I have a question regarding the resulting sizes of the blocks and shift registers in Cipher Feedback Mode.

In the web there are different pictures to illustrate the CFB-mode.

CFB

CFB_pic2

Now on the first picture there are no shift registers at all. I dont understand which special case the first picture describes. Is really the entire ciphertext (after the XOR with the plaintext) is taken as the argument in for the next block or just s bits?

What if I use the CFB-128 Mode with the following assumptions:

  1. IV size is 128bits
  2. Key is 128bits
  3. CFB-Mode is CFB128
  4. Plaintext is 256bits.

Is the resulting ciphertext of this operation always the size of the Key (128 bits in this case)? If yes is the ENTIRE ciphertext taken as the argument for the next Encryption block? I am confused about the sizes and the pictures describing it.

EDIT: Another question which I have is: What is the resulting ciphertext at the end? Is it just the last ciphertext block or is it a concatenation of all blocks (c0+c1+c2...+cn)?

$\endgroup$
2
$\begingroup$

I dont understand which special case the first picture describes. Is really the entire ciphertext (after the XOR with the plaintext) is taken as the argument in for the next block or just s bits?

It depends on what version of CFB you're using. In the olden days, they used to try to encrypt (but not integrity protect) communication channels. What some random (non-attacker generated) errors could do on these channels is insert or remove a few bits or bytes. If we consider (say) CBC mode, this insertion or deletion would cause the blocks on the sender and receiver to not line up, and so receiver would just get gibberish. What the special property of CFB-s is that, assuming if we insert/delete a multiple of s bits, the next 64 bits (assuming DES, after all, this is the olden days) would be garbled, but then (assuming no further errors) everything else would be received properly. Now, the cost of this is that each set s bits would require a separate DES encryption/decryption, however this was deemed an acceptable cost.

Now, in the more modern days, we don't care about this resynchronization property (we assume instead if the decryption result isn't exactly the same as the original plaintext, it needs to be discarded), and so if we use CFB mode at all, we use the full size (CFB-128, assuming AES, after all, we've stepped back into the modern days).

Because we don't care about CFB-s for s < 128, modern descriptions omit the shift registers (which are no longer needed).

And, to answer your questions

Is the resulting ciphertext of this operation always the size of the Key (128 bits in this case)?

Nope; the size of the ciphertext is always the same size as the plaintext, that is, 256 bits (plus the IV if you explicitly send it).

What is the resulting ciphertext at the end?

The ciphertext generated by the CFB process is all the blocks. After all, if we encrypt a 256 bit block, it'd be rather hard for the decryptor to reconstruct it if we handed him a 128 bit block...

$\endgroup$
  • $\begingroup$ Thanks for the answer. I was not precise enough with my question... Can you also tell me, what size each single ciphertext block has after XOR with the plaintext? Espscially the first one when the IV is 128bits and the key 128bits and the plaintext 256bits ? I guess it also has the size of the plaintext? $\endgroup$ – stofuser91 Jul 11 '18 at 16:32
  • $\begingroup$ @stofuser91: for CFB-128, a single ciphertext block is 128 bits; we use two ciphertext blocks to encrypt a 256 bit plaintext $\endgroup$ – poncho Jul 11 '18 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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