Re: About Peter Gutmann's critique of CIPE

> > Today, many of the functions that CIPE is trying to do, both at the crypto
> > level and at the networking level, can be done quite well by external,
> > independently developed libraries and drivers.  IMHO, to avail itself of
> > these resources would make CIPE a stronger, more lightweight solution.
> 
> CIPE is self contained as far as crypto is concerned. It is small enough to be 
> well understood and has been stable for years. It will not fail just because 
> the latest libssl contains a bug.
> 
> In many cases it makes good sense to offload functionality to standard 
> libraries - this is not such a case. CIPE contains a correct implementation 
> of all the crypto functionality it needs. Absolutely nothing is gained by 
> delegating this to a library function.

I'm not clear what your argument is against using a crypto library.  Are you
concerned about increasing executable size or relying on the correctness of
external libraries?  

On the latter point, I would say that OpenSSL has been around for quite some
time, it provides implementations of proven crypto protocols such as TLS, and
it has been subjected to a great deal of critical scrutiny due to its
widespread usage.  True, any large software project will have bugs, but the
important thing is that when vulnerabilities are announced, patches should
also be provided.  OpenSSL has been good in this respect.

The problem with implementing crypto internally is really a time/money issue.
 If you are not offloading the crypto to a library, then the responsibility
falls on your own shoulders to keep on top of security issues, which can be a
large expenditure of time and effort.  I could understand a business
allocating the resources to do this, but remember that we are dealing here
with open source -- there are a limited number of developers who are willing
to donate their time to open source projects, so why duplicate the same
efforts that are already going into maintaining the crypto libraries?

> I wish you well with your project. If you achieve the proven reliability of 
> CIPE it will be a great success. However I believe that when we leave CIPE it 
> will be for a standard product like IPsec - however that has to wait until we 
> have sufficient faith in that product.

IPsec is strong but complex, and its complexity is sometimes seen as a weakness:

Some years ago, N. Ferguson and Bruce Schneier did a security review of IPSec
and this was their conclusion:

"We are of two minds about IPsec. On the one hand, IPsec is far better than
any IP security protocol that has come before: Microsoft PPTP, L2TP, etc. On
the other hand, we do not believe that it will ever result in a secure
operational system. It is far too complex, and the complexity has lead to a
large number of ambiguities, contradictions, inefficiencies, and weaknesses.
[...] We strongly discourage the use of IPsec in its current form for
protection of any kind of valuable information, and hope that future
iterations of the design will be improved. However, we even more strongly
discourage any current alternatives, and recommend IPsec when the alternative
is an insecure network. Such are the realities of the world."

James


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