[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on a basic encryption mode
On Aug 1, 4:47pm, Steve Kent wrote:
> - As for per-packet IVs, the argument about the IP unique ID
> field may be OK for IP encapsulation, but when a transport protocol is
> directly above IPSP this argument cannot be used. Also, use of some
> hardware may be adversely affected by the need to process the first
> block in ECB mode (no IV), then switch over to CBC for the remainder
> of the packet. However, FIPS 81 does permit a fixed IV for a
> "session" in CBC mode, transmitted during session establishment and
> integrity protected. Thus use of the same IV for every packet is
> consistent with this FIPS and would avoid the per-packet overheard you
> are concerned about.
Fixed per packet IV would cause some protocols (not IP, TCP or UDP) to possibly
spill some information. If the protocol has a small number of differences in
the first doubleword, then a frequency analysis would be all that is necessary
to crack the meaning of that word.
Phil said:
>> Third, do we need an explicit IV in every packet? 8 bytes is a lot of
>> overhead, and it may not be necessary in every case to ensure "churn"
>> in the resulting ciphertext. E.g., when encrypting an IP datagram the
>> ID field will land within the first 8 bytes of plaintext, and this
>> will ensure completely different ciphertext from packet to packet even
>> if the remaining packet contents are identical.
I agree with phil. This is a real foot hold to crack a packet. If you know
through frequency analysis what the plain text of a single block is, you are a
lot further towards break it.
I do not agree, however, that it is too much overhead. For file transfers, 8
bytes added to a 1k packet is less than 1%. For transactions over a 19Kb/s line
it is less than 3.5ms added latency.
jim
Follow-Ups:
References: