More info in my AES128-CBC question

[Nicolas Williams]

On Wed, Apr 25, 2007 at 05:20:30PM +0300, Hagai Bar-El wrote:
> On 25/04/07 02:18, Nicolas Williams wrote:
> >>> But be careful.  Simply chaining the IV from message to message will
> >>> create problems (see SSH).
> 
> What problem does this (chaining IV from message to message) introduce
> in our case?

See RFC4251:

"
   Additionally, another CBC mode attack may be mitigated through the
   insertion of packets containing SSH_MSG_IGNORE.  Without this
   technique, a specific attack may be successful.  For this attack
   (commonly known as the Rogaway attack [ROGAWAY], [DAI], [BELLARE]) to
   work, the attacker would need to know the Initialization Vector (IV)
   of the next block that is going to be encrypted.  In CBC mode that is
   the output of the encryption of the previous block.  If the attacker
   does not have any way to see the packet yet (i.e., it is in the
   internal buffers of the SSH implementation or even in the kernel),
   then this attack will not work.  If the last packet has been sent out
   to the network (i.e., the attacker has access to it), then he can use
   the attack.
"

> > As long as it doesn't repeat.  Also, if it's not random then make that
> > IV the first block of plaintext (with a fixed IV) -- that is, use a
> > confounder, and make sure it doesn't repeat.
> 
> It seems as Aram uses a different IV for each message encrypted with
> CBC. I am not sure I see a requirement for randomness here. As far as I
> can tell, this IV can be a simple index number or something as
> predictable, as long as it does not repeat within the same key scope.

I think you should really consider the SSHv2 experience and add a
confounder.  The confounder plaintext block need not be random or
pseudo-random, just non-repeating.

> > A legitimate response w.r.t. confounders might be "but that wastes a
> > cipher block's worth of bits on the wire," which it certainly does, and
> > if you're really hard pressed for bandwidth and use mostly small
> > messages then you'd mind the confounder.  But I see no reason not to use
> > a random or pseudo-random IV -- a device that can do crypto can and
> > should have a decent PRNG (and a true, if low-bandwidth RNG to seed it).
> 
> I don't understand the difference between a confounder and an IV in
> terms of bits on the wire. After all, in both cases the confounder or IV
> need to be passed to the other side, unless they are implicitly known.

A confounder is an extra block of random plaintext that is prepended to
a message prior to encryption with a block cipher in CBC (or CTS) mode;
the resulting extra block of ciphertext must also be sent to the peer.

An IV is a cipher block size's worth of bits that is XORed into the
first plaintext block when encrypting/decrypting; if you somehow agree
upon an IV to use and so does not take up any bits on the wire.  If the
IV chained across continguous messages as in SSHv2 then you have a
problem (see above).  If it's constant then you have a problem that you
can solve by deriving per-message keys or by generating a pseudo-random
IV from a sequence number.

Since the protocol describe generates per-message integrity keys I
imagine that it might generate per-message confidentiality keys as well,
in which case the IV issue goes away.

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com