| 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