[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Short keys * Options, combinations, and negotiations => simplicity

>3) In software, 3DES is often nearly as cheap as DES in practice, as
>   I've found. Unless you are pounding bits really hard, your
>   bottleneck is frequently not your data transmission speed.

Some data points. My own DES and 3DES code runs at 15.9 and 6.2
megabits/sec, respectively, on a 133 MHz Pentium under BSDI. As Perry
says, this is not even noticeable over most communication paths.
Certainly not the ones I'm most concerned about, such as my ISDN
connection and the external Internet.

The 3DES code runs somewhat faster than 1/3 the speed of the single
DES code because I've removed the inner initial and final permutation
pairs that cancel each other out.

The core of the code is in hand-optimized assembler. Both GNU and
Borland C versions are included, though the GNU version is faster
because it assumes 32-bit mode. I consider my code public domain and
will email it to anyone who states they're a US citizen or permanent
resident.

I too routinely encrypt as much as I can with SSH, including all
interactive and file transfer sessions between work and home, and even
the HTTP connections between Netscape on my local machines and the web
cache over at SDSC. SSH's TCP connection- forwarding feature makes
this pretty easy to do.  And with compression also enabled in SSH,
response over my ISDN link is faster than with no SSH in the path.

Phil


Date: Wed, 16 Oct 1996 09:05:25 -0700
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199610161605.JAA03441@cornpuffs.cisco.com>
To: ipsec@TIS.COM
Subject: ISAKMP support for inline keying
In-Reply-To: <199610150214.TAA12987@mailsun2.us.oracle.com>
Organization: Internet Engineering Task Force
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

In article <199610150214.TAA12987@mailsun2.us.oracle.com> Paul Lambert wrote:

>After the working group has finished all editorial clarification of 
>ISAKMP/Oakley, work within the committee could start on incorporating 
>optional facilities for in-line keying.  I assume that this work will 
>be loosely based on SKIP with slight modifications based on working group 
>suggestions for a consolidated architecture.  

To follow up on Paul's note and clarify perhaps a bit:
	- There was significant discussion on the IPsec list about how
	  desirable it would be to put inline-keying support derived in large
	  part from SKIP within the ISAKMP framework.  The Security AD
	  has indicated that it is desirable for the WG to explore this
	  approach in detail.  Many people, including folks at Sun, have
	  indicated that this is technically feasible.  Other specific
	  suggestions (e.g. Bill Sommerfeld's idea which reduces per-packet
	  overhead) have also been made that should be considered as part
	  of the inline keying approach.

	- Therefore, Paul and I would like to ask for a volunteer or two
	  to act as document editors for a document on placing in-line
	  keying based on SKIP but incorporating other suggestions/ideas
	  from the working group into the ISAKMP framework.  Volunteers
	  should send an email to both Paul and me.  A key criterion is
	  having time to work on the document.  Another important criterion
	  is willingness to edit in accordance with WG inputs.  Should we
	  have multiple volunteers that are in other respects the same,
	  we'll probably prefer someone not at a vendor.  


To followup on Hilarie's question about ESP/AH:
	- I don't see any need to change ESP/AH in a backwards-incompatible
	  way.  I'm strongly disinclined to change ESP/AH in a backwards-
	  incompatible way because implements of the Proposed Standard RFCs
	  already exist.  My understanding from Steve Kent has been that his
	  editorial changes will not affect where the bits go (e.g. in
	  ESP with the Combined ESP transform or AH with the HMAC MD5
	  transform).

Ran
rja@cisco.com



From: PC-Waterhouse Richard <Waterhouse@nt1-ndhm.chnt.gtegsc.com>
To: 'IPSEC Working Group' <ipsec@TIS.COM>
Subject: isakmp-05.txt
Date: Fri, 18 Oct 96 16:00:00 cdt
Message-ID: <3267F332@smtp-gw.dos.chnt.gtegsc>
Encoding: 7 TEXT
X-Mailer: Microsoft Mail V3.0
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk


1. Why MUST all implementations of ISAKMP support the Internet DOI ?  We   
have a potential application that has nothing to do with thre Internet.

2. A general impression - if you are serious about "MUST", you don't have   
enough of them to nail it down to the point that interoperability is   
guaranteed.