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

To: Hans Steegers <steegers,AT,steegers,DOT,nl>
Subject: Re: CRC-32 and CipeX
From: "Eric M. Hopper" <hopper,AT,omnifarious,DOT,org>
Date: Sat, 27 Sep 2003 08:36:54 -0500
Cc: CIPE-list <cipe-l,AT,inka,DOT,de>
In-reply-to: <000701c384e4$6088e4e0$d620a8c0@pcw_hans.hnsasd.priv>
Organization: Omnifarious Software
References: <000701c384e4$6088e4e0$d620a8c0@pcw_hans.hnsasd.priv>

On Sat, 2003-09-27 at 05:44, Hans Steegers wrote:
> Since the CRC-32 checksum is **possibly** a weakness that is **relatively**
> easy to fix, I _intend_ to implement the following changes in my CipeX
> patch:
> 
> *1* I will use the two remaining unused bits in the P-byte to specify which
> checksum algoritm to use:
> 00: CRC-32 as in the current version
> 01: Another 32 bits checksum, improved algoritm (to be decided)
> 10: 64 bits checksum algoritm (to be decided).
> 11: 128 bits checksum algoritm (to be decided: MD5?).

The most cryptographically secure checksum routine that's widely
available is HMAC-SHA-1.  MD5 has some known weaknesses involving chosen
plaintext attacks.  HMAC-anything requires an additional N bits of key
information, where N is the size of the hash.

One could use the trailing 32, 64, or 128 bits of HMAC-SHA-1 in the
scheme above.  32 wouldn't be secure enough, IMHO, but it would still be
a lot better than CRC-32.

HMAC-SHA-1 needs 3 parameters:

* The data to be hashed/checksummed/whatever.
* The key information.  HMAC needs its own N bit key as I said above.
* A place to put the result (and the number of bytes of the result that
  are needed)

If you provide me with a function signature, I will use an off-the-shelf
SHA-1 implementation to write you a routine that will do the HMAC-SHA-1
for you.

I would suggest not making the checksum/hash/whatever algorithm used be
configurable.  The biggest win of CIPE is that it is trivial to
configure.  The more options there are, the less trivial it becomes.  In
particular, people tend to react in very strange ways when given choices
about cryptographic algorithms.  A secure algorithm should simply be
chosen and used, and the user should not be presented with a choice they
have to make.

I've been considering offering to be the main CIPE maintainer, but I
wouldn't be a good maintainer as I stop doing things with stuff I lose
interest in.  I am excellent to have around when you're building
something though.

The english description of the packet format for CIPE is not good
enough.  Some sort of block diagram detailing the exact layout of every
packet type is needed.  I, for example, do not fully understand the
ramifications of making the P-byte do this work.

Have fun (if at all possible),
--
There's an excellent C/C++/Python/Unix/Linux programmer with a wide
range of other experience and system admin skills who needs work.
Namely, me. http://www.omnifarious.org/~hopper/resume.html
-- Eric Hopper <hopper,AT,omnifarious,DOT,org>

Attachment: signature.asc
Description: This is a digitally signed message part


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