"Тарасов Андрей Андреевич" <admin,AT,perm,DOT,vtb,DOT,ru>|
Re: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.|
"Hans Steegers" <hsx,AT,dds,DOT,nl>|
Mon, 29 Sep 2003 13:47:21 +0200|
"Hans Steegers" <steegers,AT,steegers,DOT,nl>|
>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
The choice for CIPE was speed, elegance and simplicity with (for my use)
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
>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
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
>Correct me or ignore me if I'm wrong :)
Why should I ignore you?
Thanks for your response,