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

To: "'cipe-l,AT,inka,DOT,de'" <cipe-l,AT,inka,DOT,de>
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: Mon, 29 Sep 2003 19:11:08 +0600

> Тарасов, (Taracos?)
Sorry, national language encoding. Corporate standard and such.
Can't write from home.

> >IMHO:
> >Don't think that slowing down throughput less than 2 times is a real 
> >issue.
> For me it is a big issue: using CIPE without compression over 
> a 256 kbps
> (ADSL) link using a P150 cpu is just too frustratingly slow 
> to be usable. With compression it works great for connecting 
> two LANs. I can't afford more than 5-10% decrease in speed. 
> Slow LAN-to-LAN connections are frustrating to work with.
> The choice for CIPE was speed, elegance and simplicity with 
> (for my use) acceptable security.
> If I want to waste 50% of my available bandwidth for 
> unnecessary overhead, then there are many other alternatives 
> and no need for the effort to improve CIPE.
Well... I've been too unclear in my statements, as usual.
There are two ways of decreasing speed: 
1. increase overhead (which I'm trying to avoid)
2. Increase needs for computing power.

I've tried to ran cipe over fast ethernet and achieved 1.7 mbps uncompressed
FTP file transfer with P-225 (overclocked a bit :))
In your situation, you probably are limited by underlying bandwith more than
by CPU speed (my statement may be completely wrong in your situation,

> >Although if using SHA-1 makes it more than 2 times slower, 
> we may use, 
> >for example, another blowfish key (generated and distributed exactly 
> >under the same conditions as the main key), then reduce it 
> to 32, 64, 
> >or even 1 bit via xor operation.
> It came to my mind (HMAC-blowfish), but I still have to do 
> some research on
> it: encrypt a 32 (or 64) bit CRC using Blowfish with a 64 bit 
> secret key, for example. The components are already 
> available, and it could be a solution.
> An increased number of bytes for the appended digest is not 
> so important (a speed penalty of a few percents for full-size 
> data packets), but the CPU-overhead is. We need to find a 
> sensible and balanced compromise, that works well, even on a 
> 386 or 486.
> 1 bit? Are you joking? I am missing the point about using XOR 
> operations.
> >As far as I know, if F(X) is strong enough, then hash H(X) 
> made of F() 
> >as xoring parts of F()'s output is strong enough.
> No idea (yet).
> The only important part is that we can detect reliably if the 
> MAC is changed.
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?

If needed, I'll write a bit more detailed description of crypto-to-hash
func. Must be running by now.

> >Correct me or ignore me if I'm wrong :)
> Why should I ignore you?

Too bad english, maybe :)

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