[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ?





> -----Original Message-----
> From: Paul Koning [mailto:pkoning@xedia.com]
> Sent: 03 March 2000 19:09

> >>>>> "Chris" == Chris Trobridge <CTrobridge@baltimore.com> writes:
> 
>  Chris> The main issue with counter mode is the requirement to avoid
>  Chris> using the same values twice.  This might not sound like much
>  Chris> but it's the sort of thing that gives evaluators nightmares.
> 
> That's a fair issue, but I can't see it being a fatal problem.  The
> same requirement already exists for sequence numbers.  As has been
> mentioned already (a few weeks ago, I think, perhaps in a different
> venue) you could concatenate the ESP sequence number with the 
> block in packet number to make the counter number.

Re-use of IVs/counters is generally more serious with counter (or OFB) mode
than CBC mode.  I remember MS recently had a flaw in one of its protocols
that enabled the encryption to be broken relatively easily.  I'm not aware
of the same sort of issues having occurred with CBC.

>  Chris> I can't claim to be a crypto-scholar, but looking over the
>  Chris> publication you reference (A Concrete Security Treatment Of
>  Chris> Symmetric Encryption: Analysis Of DES modes Of Operation), I'm
>  Chris> not convinced that the attacks they mention are particularly
>  Chris> viable, at least not in IPSEC case.  The attack analysed is
>  Chris> chosen plaintext which wouldn't generally be possible.
> 
> I'd be hesitant to assume that chosen plaintext is that hard; in any
> event, it is one of the current standard tests for the security of a
> cipher.  (If a cipher is secure against known plaintext but not
> against chosen text attack, that is no longer considered acceptable.)
> 
> 	paul

For a plaintext attack, the adversary has to be able to ask you encrypt
arbitrary plaintext and return him the corresponding cipher text.  In the
CBC case he also needs to be able to specify or predict the IV.  The text
suggests that encrypting the IV would protect against plaintext attack.  In
any case in an IPSEC system the adversary wouldn't normally have access to
both plaintext and ciphertext let alone be able to specify plaintext - the
initial portion of plaintext is a header and the IV and payload are
protected by a MAC.

That said, it's better to have an algorithm that is generally strong rather
than just in the assumed operating conditions.  Encrypting the (transmitted)
IV before use would solve this.

Chris