<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: 'Hans Steegers' <steegers,AT,steegers,DOT,nl>
Subject: RE: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.
From: Тарасов Андрей Андреевич <admin,AT,perm,DOT,vtb,DOT,ru>
Date: Tue, 30 Sep 2003 11:18:12 +0600
Cc: CIPE-list <cipe-l,AT,inka,DOT,de>

Hi Hans & everybody!

> Hi Taracos (?),
> >> ôÁÒÁÓÏ×, (Taracos?)
> >>
> >Sorry, national language encoding. Corporate standard and 
> such. Can't 
> >write from home.
> Doesn't matter, I just was curious if I translated the 
> russian alphabet correctly.

Close to that :)
Tarasov would be more correct.

> >I've tried to ran cipe over fast ethernet and achieved 1.7 mbps
> uncompressed
> >FTP file transfer with P-225 (overclocked a bit :))
> What do you get without CIPE?

Never tried. 
If you ask about bandwith, it's asymmetric and is varying from 512 to 800 k
in the slower direction.

> >Another idea just popped up in my mind: why we can't just put CRC32 
> >into encrypted part of the message, and control consistency of the 
> >message
> after,
> >say , "blind" decription? This just won't let any open part 
> that could 
> >possibly be analyzed and corrupted, except for the whole message?
> >
> This looks like an example of synchronicity: Mark came with 
> the same idea. See the list for the responses. It is worth to 
> investigate.

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 :))

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.

<< | Thread Index | >> ]    [ << | Date Index | >> ]