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

To: "Тарасов Андрей Андреевич" <admin,AT,perm,DOT,vtb,DOT,ru>
Subject: Re: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.
From: "Hans Steegers" <hsx,AT,dds,DOT,nl>
Date: Mon, 29 Sep 2003 13:47:21 +0200
Cc: "CIPE-list" <cipe-l,AT,inka,DOT,de>
Reply-to: "Hans Steegers" <steegers,AT,steegers,DOT,nl>

Тарасов, (Taracos?)

>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.

>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.

>Correct me or ignore me if I'm wrong :)

Why should I ignore you?

Thanks for your response,

Hans Steegers


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