[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions on IV for ESP payload
Loretta Zhou wrote:
>
> Hi,
>
> I have some questions on the creation and the size of IV
> for ESP payload.
>
> RFC 2407 defines the following IPSEC ESP Transform Identifiters:
>
> Transform ID Value
> ------------ -----
> RESERVED 0
> ESP_DES_IV64 1
> ESP_DES 2
> ESP_3DES 3
> ESP_RC5 4
> ESP_IDEA 5
> ESP_CAST 6
> ESP_BLOWFISH 7
> ESP_3IDEA 8
> ESP_DES_IV32 9
> ESP_RC4 10
> ESP_NULL 11
>
> It also indicates the following for the transform ids:
>
> o For ESP_DES_IV64 (1) and ESP_DES_IV32 (9), the transform type
> specifie the DES-CBC transform defined RFC-1827 and RFC-1829.
>
> o For ESP_DES (2), all implementation within the IPSEC DOI MUST
> support the suite defined as [DES] transofrm (RFC2405).
>
> o For ESP_3DES (3), all implementation within the IPSEC DOI MUST
> support the suite defined as [ESPCBC] transofrm (RFC2451).
>
> By looking at the 3 RFCs mentioned above for information on IV,
> RFC1829 says that "A common acceptable technique is simply a counter,
> beginning with a randomly chosen value", while RFC2405 and RFC2451
> indicate that "Common practice is to use random data for the first IV
> and the last 8 octets of encrypted data from an encryption process as
> the IV for the next encryption proces".
In section 6 "Security Considerations" of RFC 2405 Steve Bellovin is
quoted:
"The problem arises if you use a counter as an IV, or some other
source with a low Hamming distance between successive IVs, for
encryption in CBC mode. In CBC mode, the "effective plaintext"
for an encryption is the XOR of the actual plaintext and the
ciphertext of the preceeding block. Normally, that's a random
value, which means that the effective plaintext is quite random.
That's good, because many blocks of actual plaintext don't change
very much from packet to packet, either.
For the first block of plaintext, though, the IV takes the place
of the previous block of ciphertext. If the IV doesn't differ
much from the previous IV, and the actual plaintext block doesn't
differ much from the previous packet's, then the effective
plaintext won't differ much, either. This means that you have
pairs of ciphertext blocks combined with plaintext blocks that
differ in just a few bit positions. This can be a wedge for
assorted cryptanalytic attacks."
It then goes on to note
The discussion on IVs has been updated to require that an
implementation not use a low-Hamming distance source for IVs.
which I take to mean no counters.
> At the mean time, appendix B of RFC2409(The Internet Key Exchange)
> states the following:
>
> In phase 2, material for the initialization vector for CBC mode
> encryption of the first message of a Quick Mode exchange is derived
> from a hash of a concatenation of the last phase 1 CBC output block
> and the phase 2 message id using the negotiated hash algorithm. The
> IV for subsequent messages within a Quick Mode exchange is the CBC
> output block from the previous message. Padding and IVs for
> subsequent messages are done as in phase 1.
>
> Q1) Should we create the first IV using a random number or using
> the algorithm defined in appendix B of RFC2409? If we follow
> RFC2409, do we store IV (last phase 1 CBC output block) as part
> of the SA fields?
My understanding is that the algorithms of RFC 2409 apply only to the
contents of the messages exchanged over the ISAKMP SA. In this case the
IVs are not included in the packets and so cannot be random.
I can't answer any more of your questions since I don't know the answers
:-(
--
The opinions expressed in this message are my personal
opinion and in no way reflect the views of my employer.
Søren Kierkegaard says
"Life can only be understood backwards; but it must be lived forwards."
References: