RE: Data integrity check in CIPE - Please explain me the necessit yor benefit of a larger checksum.

> Тарасов, (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,
though!)

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

--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>