[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
calculating IVs
> From: Matt Thomas <matt.thomas@altavista-software.com>
> The IV is defined for SAs with negotiated keys as based on the
> SPI and replay counter:
>
> When dynamically configured via a key management protocol, the 64-bit
> IV is generated from the 32-bit SPI field followed by (concatenated
> with) the 32-bit Sequence Number field. The bit-wise complement of
> the 32-bit Sequence Number value is XOR'd with the first 32-bits
> (SPI).
>
> My question is why? I read the security notes but I still can't figure
> out the above is specified.
A really thorough explanation takes several pages. I'm working on a
"white paper" to collect the previous discussion.
Suffice it to say, that was the _compromise_ reached over a year ago.
It was the second compromise method. It is a little stronger than the
first compromise reached over 2 years ago, described in RFC-1829 and
RFC-1851. One of the problems with this group is no decision stands for
more than a year. And everything has to be explained all over again to
each new person, such as yourself.
The "best" method would be to key DES-OFB over SPI+Sequence and use that
for the IV. Easy in software, but the hardware manufacturers griped
that would cause 2 chip invocations, and slow down their implementations.
However, since then it has appeared that the "best" method can be done
with 1 invocation in CBC mode, and then replace the generated ciphertext
in the packet with the original SPI+Sequence. Simple. Elegant.
I would be willing to change. Ask the vendors that implemented RFC-1851
if they would be willing to change....
> Both the RC5 and CAST ESP drafts use a
> pseudo-random IV which is discarded. That's makes much more sense to me.
Bad choice. Go read "Abusing IVs" in "Problem Areas for the IP Security
Protocols" [Bellovin95, 96]. Or the referenced Voydock-Kent83.
> By defining the 3DES IV as above, doesn't this give an attacker a really
> good source of plaintext to try to crack the keys?
>
> Am I missing something fundamental here?
Yes.
Both methods provide exactly the same amount (64-bits) of known text.
The IV is XOR'd with the first plaintext block before encrypting.
Therefore, the IV isn't really plaintext on its own, as any good
encryption algorithm will sufficiently obscure the result.
A separate IV allows potential for changing bits in the first block.
Particularly bad for UDP without checksums.
Using the SPI and/or Sequence causes the packet to be misdirected or
discarded if the SPI or Sequence are changed. Much better protection.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: