Re: comments on draft-ietf-ipsec-new-esp-00

[Steven Bellovin <[e-mail]>]

> >The draft should probably state that the IV should always be a multiple of
> >32 bits.
> >Or require multiples of 64 for IPv6.
> 
> 
> Well, this is really an algorithm independence issue.  We don't get to pick
> IV lengths; they are defined by the algorithms.  However, we can require
> this field  to be a multiple of 32 bits and note that if the real IV does
> not conform to this requiremend, then the algorithm spec will describe how
> padding is performed.

No -- your first instinct is right.  The <IV,ciphertext> pair is
opaque to any level above the decryption routine; thus, higher-level
routines can neither known nor care if one is present.  At most, the
existence of one is a parameter to be passed from the key negotiation
layer straight through to the encryption/decryption layer.

Let me give a concrete example.  In, say, DES-CBC, the IV can be seen
as the first block of ciphertext; it's decrypted with any IV
whatsoever.  The only difference is that the first block of the
resulting plaintext -- that is, the plaintext that comes from the
(conceptual) decryption of the IV -- is discarded.  Seen this way,
the difference between the IV and some other portion of the ciphertext
is irrelevant.

We can carry this further by assuming a block cipher with an 80-bit block
size, and hence 80-bit IV.  Why would we want to pad the IV?  Again, it's
just part of the input to the decryption engine.

Decisions on the format of the <IV,ciphertext-blocks> field belong in the
RFCs describing individual transforms.  Those documents can and should
consider block alignment and efficiency considerations for likely
implementation techniques.