RE: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.|
Тарасов Андрей Андреевич <admin,AT,perm,DOT,vtb,DOT,ru>|
Mon, 29 Sep 2003 19:11:08 +0600|
> Тарасов, (Taracos?)
Sorry, national language encoding. Corporate standard and such.
Can't write from home.
> >Don't think that slowing down throughput less than 2 times is a real
> 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
> >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 :)