RE: Data integrity check in CIPE - Please explain me the necessit yor benefit of a larger checksum.|
Тарасов Андрей Андреевич <admin,AT,perm,DOT,vtb,DOT,ru>|
Tue, 30 Sep 2003 18:55:12 +0600|
> On Tue, 2003-09-30 at 00:18, Тарасов Андрей Андреевич wrote:
> > I must apologise for being too hasty.
> > As follows from the protocol.txt, checksum is already
> transferred in the
> > encrypted part of the message, so all transmission over
> cipe tunnel is
> > secure as long as secret key is secure. Of course, stronger
> hash will
> > improve things, but there are no immediate danger (in my
> hasty opinion :))
> I need to read this carefully and make up some nice diagrams and
> descriptions that are easier to understand at a glance. The
> in protocol.txt looks mostly complete, but it's not the kind
> of document
> I find easy to get a picture of what's going on from.
It's easy (somebody already written this, drawing got from Olaf's posting):
? octets flags ##
n octets payload data #
p octets padding # encrypted
4 octets checksum ##
Something like that.
So, CRC cannot be analyzed or changed without knowing/changing other data or
knowing the key. This can be considered secure.
There is one theoretical hole - when some non-TCP protocol is used as a
payload and size of particular packet is known to be congruent three modulo
eight - so no padding occurs. This protocol can be vulnerable to
known/chosen plaintext attack. Don't think it's a serious breach in
> If the CRC is inside, then I agree, that's much better. As
> I've pointed
> out elsewhere, it does make the attacker's job harder, but
> it's hard to
> quanitify how much harder. Using a secure hash would make it possible
> to say just how hard it was.
It's easy to quantify - attacker must break the blowfish key using other
fields of the packet. In worst case, consider attacker having encrypted
packet without random padding and CRC - because CRC is encrypted with block
of payload and/or random data.
> > Man in the middle can force using secret key more often,
> and may also ran a
> > DOS attack, but don't think that we can handle this with a
> simple patch.
> > Being in the middle is too powerful position anyway. For
> example, one can
> > flood you with total garbage on cipe ports (with source
> address spoofed),
> > and I see no protection.
> I will have to look at how the timestamps are used, computed and
> checked, but it might be possible for a MITM to force the use
> of an old
> dynamic key as well.
That's quite possible. KX can be considered not very well protected (olaf's
said that). In worst case, protection relies on secrecy of the secret static
key, which is changing rarely. But this hole is very hard to exploit.