[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Derived versus Explicit technical rationale




Hi,

Somebody asked me, in a private message, to comment on the issue of 
derived vs explicit IV.
I'll share my response with you (all of the arguments below have already
been presented in this list in the past - as everything else, I guess)

Forwarded Message:

I haven't followed closely the group discussion.
In general, it is best to have an IV which is unpredictable
and, if possible, secret.
This can be achieved by computing a secret function (e.g. depending
on a shared key) on a sequence number or any other strictly changing field
transmitted with the packet.

In any case, the method of draft-ietf-ipsec-ciph-des-derived-00.txt:

   By default, the 64-bit IV is generated from the 32-bit ESP Sequence
      Number field followed by (concatenated with) the bit-wise complement
      of the same 32-bit value:
   
         SN || -SN

does not achieve any of the two desired properties, namely,
it is both predictable and exposed.

Secrecy of IV can help avoiding collection of plaintext-ciphertext
pairs through the first block which may be easier to predict by an 
attacker than subsequent blocks.
(Notice that if the secret IV is derived from a known quantity using the
same key used to encrypt the rest of the message then not much is gained as
for avoiding plaintext-ciphertext pairs).

Unpredictability of IVs was "praised" in the ipasec list several times
(I remember messages on this by Prennel, Roe, Rogaway and others).
Attached is a recent note of myself to ipsec on this recurrent subject.


   Date: 7 January 1997, 10:31:29 EST
   From: HUGO at WATSON
   To:   bhoward at TimeStep.com, chk at border.com, URI at WATSON
   cc:   ipsec at tis.com
   Subject: pf_key comments (predictable IVs)
   Sender: owner-ipsec@ex.tis.com
   Precedence: bulk
    
   The traditional motivation for IVs is to cause two encryptions of the
   same plaintext to result in two different cipheretexts.
   For such a use just different (even if predicatable) IVs are enough.
   However, there is more functionality built into IVs.
   They are intended to randomize plaintext before encryption for a variety of
   other reasons.  Especially, against chosen message attacks.
    
   Consider, for example, an attacker that builds a table with encryptions
   of the all-zero message under the 2^56 DES keys.
   How does the guy gets an encryption of zero under the victim's key?
   If the attcker can mount a chosen plaintext attack it could ask for the
   encryption of the zero message. But if the encryptor chooses an IV before
   encrypting then the attacker gets DES(K,IV) rather than DES(K,0).
    
   On the other hand, if the IV is known to the attacker before hand (e.g., the
   IV is an incrementing counter or the last block of ciphertext from the
   *previous* message) then the task for the attacker is easy.
   He just chooses the message to encrypt to be equal to the next IV.
   The ciphertext he will see is DES(K, IV XOR IV) = DES(K,0) !
    
   If instead, the IV is chosen *after* the plaintext is fixed (in a way which
   is unpredictable to the attacker) then the attacker has little to do
   to get DES(K,0).
    
   I hope this helps in clarifying the issue of predictable vs unpredictable IVs.
   In particular, IVs known *before* choosing/fixing the message to be
   encrypted or *after*.
    
   Another example from Phil Rogaway (draft-rogaway-ipsec-comments-00.txt):
    
    "...suppose the IV is  a sequence number: 0, 1, 2, ... .
     Then a (first) encryption of 0x0000000000000000 followed by an encryption of
      0x0000000000000001 is recognizably distinct from a (first) encryption
      of 0x0000000000000000 followed by an  encryption of
      0x0000000000000000.  Clearly this violates violates the notion of a
      secure encryption sketched in Section 2."
    
    [You can find the full Rogaway's draft in
     http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/list.html
     A related one in the same page is:
     draft-rogaway-cbc-encrypt-00.txt (April 27, 1995)]
    
   Hugo