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

To: cipe-l,AT,inka,DOT,de
Subject: Re: About Peter Gutmann's critique of CIPE
From: Christoph Biedl <cbiedl,AT,gmx,DOT,de>
Date: Fri, 26 Sep 2003 16:38:48 +0200
In-reply-to: <C823AC1DB499D511BB7C00B0D0F0574C584153@serverdell2200.interclean.com>
References: <C823AC1DB499D511BB7C00B0D0F0574C584153@serverdell2200.interclean.com>

David Brodbeck wrote...

> > -----Original Message-----
> > From: Allan Latham [mailto:alatham,AT,flexsys-group,DOT,com
> > 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.

"The next version will use the cryptographic API". That's what I read
about cipe somewhere. Or is there a difference between using a library or
a part of the kernel?

> I'm not sure I agree with this argument.  Can you be *sure* that your
> implementation is more correct than any library version?
> The example I'm thinking of here is the zlib buffer overflow.  Programs that
> used the shared library were easy to fix just by replacing the library.
> Unfortunately a lot of people didn't want to rely on the library, and had
> cut-and-pasted the code into their own software, security hole and all.
> Those programs are *still* being tracked down and fixed, while the ones that
> simply used the library instead of reinventing the wheel are secure.

Indeed. And two things beside:
- The code shared from somewhere else is surely under a better code
  review, especially the cryptographic stuff.
- Security issues there will not harm cipe's damaged reputation[1].


[1] Two people I know decided to replace their cipe setup by something
    else after reading Olaf's message. Although freeswan will be very
    hard to set up in their configuration, as they told me.

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