Re: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.

Eric,

Thanks, an excellent, constructive response!

1,2,5. So we need HMAC (which is encryption of the digest) for any
improvement and the checksum size alone isn't relevant. So, we need also a
second key. Using the same key as for encryption would make it easier to
break that key.

3,4. I am not yet convinced here it is that easy: slightly modified packets?
Of the non-encrypted part: yes. Of the encrypted part: you still can't
predict the result without some insider info and it may work only for very
limited and unlikely circumstances. Anyway, using HMAC for integrity
checking makes this impossible.

>Can you state with any certainty that a protocol requires x amount of
>computation to break without compression, and x + y with?
No, that is the wrong relation: it makes certain attacts more difficult or
even impossible, because the packet size is no more related to the original
packet size and the location of the contents can't be predicted. For other
types of attacts it doesn't make a difference. There is no linear relation.

>Proper data integrity checking fills this role nicely.  You can give
>hard limits on those things.  I can tell you that the lower bound on the
>chance that an attacker can successfully spoof a packet is 2**-24
>(birthday attacks halve the effective number of bits) if you have 48
>bits of HMAC-SHA-1 data at the end with a secure HMAC key.
Yes I have seen that, but HMAC-SHA-1 is too CPU-intensive if you are not
using or needing all 160 bits. There must be a simpler (more balanced) way
to 'encrypt' the message digest that is less CPU-demanding and protects the
data integrity checking. HMAC-SHA-1 is just as CPU-demanding if you use only
32 bits or using all 160 of them.
Using HMAC-SHA-1 will make CIPE unusable on slow CPUs and/or on very fast
media. My first guess (evaluating some implementations) is that this scheme
is at least 1000x more CPU-demanding (and time consuming) as the current
CRC-32.

>I've been studying cryptography and cryptographic protocols for the past
>2-3 years.  I won't make any statements about my credentials, but I do
>know for certain the Peter Gutman's arguments are valid, and that the
>solution I propose will significantly improve things.
I don't want to be rude, but why didn't you find this 'weakness' then?
I can't imagine that somebody who studies cryptographic protocols and uses
CIPE didn't see the use of an unprotected CRC-32 and it's weakness. The
source was available all the time and the protocol description didn't make
it a secret.
P.Gutmann was at most partly right: some of his assertions were plain wrong.
He is well regarded by some and completely ignored by others.
The solution you suggests is valid, but overkill and would ruin CIPE's
usability on anything but fast CPUs and slow media. We should avoid that if
there are alternative solutions providing the same protection: speed is very
important here.

In summary, my conclusions (so far) are:

1. There is no benefit in using a larger checksum. Checksum length is of no
influence on security if no HMAC is used.

2. We need HMAC for a lighter (less cpu-demanding) message digest of say 64
bits.
Using SHA-1 and use only a small part of its output is overkill, a waste of
CPU-time and would make CIPE unusable on slow CPUs and/or fast media.
There must be a (cpu-wise) lighter (faster) solution available which also
provides the required protection. We need this protection for a maximum of
the dynamic key's life time. Any ideas?

3. We need a second secret key for the HMAC, in order not to expose the
first secret key. This is unfortunate, because it makes the configuration
more complex.

Thanks again,

Hans Steegers




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