[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ipsec-skipjack-cbc-00.txt
>>>>> "Philip" == Philip Gladstone <philip@raptor.com> writes:
Philip> "Steven M. Bellovin" wrote:
>> >Secondly, there's a much more serious technical problem with
>> your draft, >in that by using an implicit IV and a sequence
>> number, it looks like >you're assuming that IV is chained across
>> packets. If that is the case, >it has a significant problem in
>> that it you force the IPSEC engine to >handle reordering, and even
>> worse, it has no way to recover from a >dropped packet.
>>
>> Actually, no -- given CBC's properties, a dropped packet implies
>> that the following packet will not be decryptable; however, the
>> last block of its ciphertext can still be used as the IV for the
>> next packet. You thus square the effective packet loss
>> probability. Reordering is still a significant hassle for the
>> receiver, however.
Philip> Worse, the use of the last block as the IV for the next
Philip> packet breaks the assumption that IVs are unpredictable. Note
Philip> that if IVs were predictable, and you could persuade the
Philip> endpoint to encrypt packets for you, then you could perform
Philip> test encryptions where you control the input. This is very
Philip> bad.
I don't suppose it's ideal, but that sounds like a chosen plaintext
attack, which is something that good cryptosystems should be able to
cope with.
Apart from that, the explicit IV RFC has the same property: it
describes chaining from one block to the next as a "common practice"
(RFC 2451, top of page 8). There isn't any assumption that IVs are
unpredictable -- the preceding packet will tell you what it will be in
implementations that use that "common practice". What is required is
avoiding low Hamming distance, which chaining will do (as will the use
of a separate random IV per packet).
paul
Follow-Ups:
References: