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

To: Les Mikesell <les,AT,futuresource,DOT,com>
Subject: Re: About P.Gutmann's critique of CIPE - etc. etc.
From: "R. Steve McKown" <rsmckown,AT,yahoo,DOT,com>
Date: Fri, 26 Sep 2003 09:10:47 -0600
Cc: CIPE-list <cipe-l,AT,inka,DOT,de>
In-reply-to: <1064580484.27236.24.camel@les-home.futuresource.com>
References: <003901c38425$3fcf1c20$d620a8c0@pcw_hans.hnsasd.priv> <1064580484.27236.24.camel@les-home.futuresource.com>

On Friday 26 September 2003 06:48 am, Les Mikesell wrote:
> Can someone comment on what CIPE still has as an advantage over OpenVPN
> (does it have blowfish?)

OpenVPN has blowfish and it is the default cipher for tunnel encryption.  See 

CIPE's total code size is an order of magnitude smaller than the code size of 
just the openssl library.  Over the life of a software product, there is a 
direct correlation between code size and both total defects and maintenance 
cost (time, effort).  Not all defects are exploits (perhaps most aren't), but 
all exploits by definition derive from defects.

OpenSSL is a high-quality library that stands heads and shoulders above other 
such solutions; it's the right tool for many needs.  I just want to point out 
that all else being equal, simplicity wins.  CIPE has value, I believe, 
because many situations don't require the vast array of features openssl 
carries and therefore don't necessarily need to embrace the unneeded 

> [snip]
> However, since I also tend to run ssh and ssl connections
> on the same server (yes, I know it's a bad practice...) I'll have
> to keep those libraries up to date anyway and it makes a certain
> amount of sense to have the same crypto libs do everything.

There are two competing variables: diversity and complexity.  If all your 
crypto apps are based on openssl, you might decrease the complexity of your 
IT systems by reducing the number of components you have to manage (updates, 
vulnerabilities, etc).  However, in this case a vulnerability in openssl may 
compromise multiple crypto apps.  With crypto apps that rely on different 
underlying components you increase diversity, create some isolation between 
those apps in the case of compromises, ... and increase complexity.

All else being equal, simpler is better.  If compromise of crypto in your 
environment is exceptionally costly, more diversity may be required.  If not, 
you've a good case for reducing complexity.

All the best,

Steve McKown
Titanium Mirror, Inc.

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