4
$\begingroup$

I've implemented this algorithm, which, working from the end of the message backwards, creates a valid CBC ciphertext from any plaintext, using the block cipher's decryption operation instead of the encryption operation.

CBC

I bet this is described in the literature, somewhere. Possibly as a bad idea.

My questions:

  1. What is this method/algorithm/construction called?
  2. Is it as secure as CBC implemented the normal way?
  3. Do the normal rules for CBC IV apply to the last ciphertext block or not?

For those wondering why I would want to encrypt my message from the end, this is an exercise in exploiting a padding oracle attack (against my own dummy code running on my own server).

$\endgroup$
  • $\begingroup$ Personal evaluation (don't take it for sure but rather for feeling): So this is CBC starting at the end and using decryption rather than encryption direction? 2) This should be as secure as standard CBC, 3) they should, 1) I don't know if anyone actually proposed this one yet, I doubt it because normally people tend to encrypt messages at the start which has some practical advantages (you can start encrypting without buffering the whole message)... $\endgroup$ – SEJPM Aug 1 '15 at 21:34
  • 1
    $\begingroup$ If the IV is reused then you can XOR the middle ciphertext block with another one to retrieve the last plaintext XOR'ed with the other plaintext. $\endgroup$ – Maarten Bodewes Aug 1 '15 at 21:38
5
$\begingroup$

What is this method/algorithm/construction called?

Dunno; this is a new one on me.

Is it as secure as CBC implemented the normal way?

Should be. Modeled as an abstract 'take plaintext, output ciphertext' model, this method (with a random last ciphertext bits) has precisely the same ciphertext output distribution as CBC mode (with a random IV), and so from that standpoint, it's just as good. And, I don't see any extra side-channel type attacks (that is, attacks that listen into the encryption procedure).

Do the normal rules for CBC IV apply to the last ciphertext block or not?

Actually, lesser restrictions apply. With the standard CBC mode implementation, you need to generate the IVs unpredictably (if you don't, there are possible chosen plaintext attacks). With this, you need only uniqueness (and please don't deliberately copy a previous ciphertext block) in the random last ciphertext bits. That can be seen by looking at the block cipher as a random Oracle; as long as the last ciphertext block hasn't been seen before, then the attacker will have no information on resulting 'encryption' of that block (other than that it's a value he hasn't seen before); as long as you're under the Birthday Bound, you don't have to accidentally reissuing a ciphertext block. Hence, while using a counter to generate IVs with the standard CBC mode is a Really Bad idea, it's actually safe here.

$\endgroup$
5
$\begingroup$

Your mode is essentially equivalent to CFB mode, except that:

  1. you've reversed the order of the blocks in the message, and
  2. you're using the block cipher in the opposite direction than usual.

CFB mode encryption

Neither of those differences should have any direct security implications (since all standard block ciphers have the same security properties in both directions), so your scheme should be just as secure as CFB mode.

$\endgroup$

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.