[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-ipsec-new-esp-00
> >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.