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

To: "Eric M. Hopper" <hopper,AT,omnifarious,DOT,org>
Subject: Re: Data integrity check in CIPE - Please explain me the necessityor benefit of a larger checksum.
From: hans steegers <steegers,AT,steegers,DOT,nl>
Date: Mon, 29 Sep 2003 21:00:19 +0200
Cc: cipe-l,AT,inka,DOT,de
In-reply-to: <1064851787.23120.28.camel@monster.omnifarious.org>
Organization: steegers
References: <000b01c3865f$f66d9e20$d620a8c0@pcw_hans.hnsasd.priv> <1064851787.23120.28.camel@monster.omnifarious.org>

Op maandag 29 september 2003 18:09, schreef Eric M. Hopper:
> Yes.  HMAC is also designed to protect against specific weaknesses that
> almost all currently used message digest algorithms have.
Fine!

> It is relatively trivial to flip a bit in a given CBC block.  The cost
> is the improper decryption of the next block.  If the CRC is on the
> encrypted data, then the CRC is absolutely useless for preventing this.
> Only the internal IP and TCP/UDP checksums will help.  And they are also
> susceptible to having their bits modified predictably.
You don't have to repeat yourself. If we are not using CRCs this is not 
relevant anymore. Parrotting examples from textbooks all over again isn't 
very productive. I know you want HMAC-SHA-1 by now, but more and more I 
wonder if that is the right choice.

> So, if I compress a 50 byte packet and a 100 byte packet, the 100 byte
> packet has no chance of being distinguished from the 50 byte packet?
> In other words, will the compressed packet of 50 bytes have a 50% chance
> of being larger than the compressed packet of 100 bytes?  Can you
> quantify with hard numbers how much harder it would be?
The compressabillity depends on the contents. A compressed 50 byte block can 
and is often larger than a compressed 100 byte block. Since I don't know the 
contents, quantification is impossible. 
I made some tests on compressability of various small blocks: even a gzipped 
file transfer results in packets of various sizes: some chunks are 
compressible, others aren't. The compression ratio on small datablocks 
(250-1400 bytes) with various contents is **very** unpredictable. The ratio 
varies (IIRC) between 1 and 20!

> When I use a protocol, I want hard, definite bounds that tell me exactly
> how secure it is.  If the CIPE CRC is over the encrypted packet (which
> it seems to be), then the attacker can trivially (in less than 2**8
> steps) and predictably modify any block in the packet, without knowing
> the key, at the cost of creating a random block following.  This isn't
> very secure at all.  In fact, I would consider this criminally insecure
> in a commerical system.
Fine. But please, sentences as "it seems to be" are in contrast with a proper 
analysis. I can read those books and articles too. You are overstepping 
yourself more and more.
I would suggest: make an exploit for CIPE and we can see how vulnerable it 
is. 
Then we have also a tool to test the protocol. 

> I don't care how much HMAC-SHA-1 costs, it should be an absolute 
> requirement.
Come on: SHA-1 is not the only possible solution. I do care about the costs.
If it costs too much CIPE has no advantage any more: we then better abandon 
it 
completely: all efforts would be wasted. I am looking for a minimum-effort 
and balanced solution.

A steel door with a window of 4-mm glass provides no security at all. The 
chain is as strong as the weakest link. etc., etc,..

> > 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.
> Oh, well.  There are many fast, insecure protocols in the world.  I
> don't think we need another one.
This is a stupid remark when we are looking for a minimum effort solution to 
an _existing_ protocol. Implementing HMAC-SHA-1 will probably make CIPE loose 
its main advantage: speed. You are becoming annoying.

> > >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.
> Partly because I didn't study the CIPE protocol with an eye towards
> finding weaknesses.  Also, partly, because my experience is limited to
> reading books or designing things, I'm still not that good of an
> analyzer of other protocols.  It is much easier to recognize a bug when
> it is pointed out than to discover it.
Bullshit: there was nothing to discover, just reading Protocol.txt. And there 
is _NO_BUG_!!! (This is FUD!) And as a wannabee cryptographer, one should 
expect you read at least the protocol description of the protocol you use. 
And as a programmer you should at least be curious about the implementation.
And now calling it 'another insecure protocol' contradicts all your 
advertised 
expertise.

For me it was no surprise at all: I knew about the tradeoff between security 
and speed + simplicity: I judged the security as sufficient for my purposes.
I don't care, for example, if somebody tries to replay a sequence of 
datagrams: it will do no harm here.

What makes me very, very **angry** is those commercial people selling CIPE to 
customers as ultra-secure without having evaluated CIPE properly. And the 
same people are now crying faul and demand it fixed! 
For greed and profit and advertising non-existent expertise. That is criminal!

> I would guess that a K6-450 could easily handle a T1 line with
> HMAC-SHA-1.  My CIPE server is an old P-90, but that will probably
> change within a year.  That server actually adds (not just for CIPE) 1
> or 2 milliseconds of latency to every packet.  When my latency to the
> Internet as a whole is at best 40 millseconds, this isn't a big deal,
> but it's still annoying.
Nobody needs this guess: I have tested the overhead with one of the fastest 
compression algorithmes I could find, and on fast 1 - 2 Mbps links you need a 
really fast CPU to have gain from the compression. 
Evaluating the code of some of the implementations of SHA-1 (in the kernel 
for 
example) and comparing it to the compression code, I _expect_ a huge penalty.
So I keep shopping for faster alternatives.

Keep in mind that I am looking for a minimum effort solution, that is easy to 
implement (say within a week or two) and solves the most important concerns.
I don't need Fort Knox security: that isn't my interest at all. I need 
**sufficient** security at a minimum speed penalty. 

Let those commercial guys implement the security they want (if they can).
Why should I help them make money without anything in return?

A re-designed protocol and a new implementation is a complete different 
matter. Using the new kernel facilities, the user can choose from many 
options: from ultra secure and very slow to less secure and very fast.
The kernel provides all the crypto/compression services you need. HMAC-SHA-1 
is one of them.  (Invest your time and study those!)
However re-designing the protocol and re-implementing it should NOT be done 
hastely and implementation will probably not be started this year.

Take care,

_____________________________________________

Hans Steegers


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