Re: Stream Cipher Transform -- revisited
"Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" <tld5032@commanche.ca.boeing.com> Wed, 31 July 1996 00:21 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa29984; 30 Jul 96 20:21 EDT
Received: by relay.hq.tis.com; id UAA00802; Tue, 30 Jul 1996 20:24:24 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma000796; Tue, 30 Jul 96 20:23:55 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA05709; Tue, 30 Jul 96 20:23:27 EDT
Received: by relay.hq.tis.com; id UAA00793; Tue, 30 Jul 1996 20:23:54 -0400
Received: from atc.boeing.com(130.42.28.80) by relay.tis.com via smap (V3.1.1) id xma000791; Tue, 30 Jul 96 20:23:31 -0400
Received: by atc.boeing.com (5.65/splinter.boeing.com) id AA26679; Tue, 30 Jul 1996 17:09:10 -0700
Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA258358450; Tue, 30 Jul 1996 07:54:10 -0700
Received: by commanche.ca.boeing.com (AIX 4.1/UCB 5.64/4.03) id AA21468; Tue, 30 Jul 1996 07:55:10 -0700
Message-Id: <9607301455.AA21468@commanche.ca.boeing.com>
To: Germano Caronni <caronni@tik.ee.ethz.ch>
Cc: ipsec@TIS.COM, skip-info@tik.ee.ethz.ch, markson@incog.com, dpalma@netcom.com, Project SKIP <skip@tik.ee.ethz.ch>, Burkhard Stiller <stiller@tik.ee.ethz.ch>, Bernhard Plattner <plattner@tik.ee.ethz.ch>
Subject: Re: Stream Cipher Transform -- revisited
In-Reply-To: (Your message of Wed, 03 Jul 96 14:42:10 +0200.) <199607031242.OAA10521@kom30.ethz.ch>
Date: Tue, 30 Jul 1996 07:55:09 -0700
From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" <tld5032@commanche.ca.boeing.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Germano Apologies, I have been intending to reply but summer kept getting in the way. Anyway a couple comments and thoughts on including support for stream ciphers in IPSEC as I believe there is a strong security and business case for their use. 1) In general most of us have substantial numbers of legacy systems or over-subscribed systems which have minimal amounts of un-used cycles. It is very difficult to justify, and often to operationally implement, a high-overhead encryption mechanism which results in the capacity of 100 user production server being reduced to 60 or 70. 2) In many cases absolute security of the data may not be justified but prevention of re-play attacks or session-hijacks is essential, especially in light of on-going work on "single sign-on functions". It would seem that light weight ciphers might be ideal here. 3) For now, regardless of our personal views, exportability of a solution is very important. It seems likely that ciphers may be more generally exportable and having more exportable options would appear to be win. 4) As you note, protection of "content" from alteration during delivery is also key, whether you are working with "web data", realtime video, or voice. Again the low-overhead of ciphers looks attractive for this type of use. I encourage your group to continue the work as I believe that support of low-overhead encryption techniques will considerably broaden the usability of IPSEC. Take care | Terry L. Davis, P.E. | Boeing Information & Support Services | | 206-957-5325 | tld5032@atc.boeing.com. | --------------- Tuesday July 30,1996 07:27 AM PDT -------------
- Stream Cipher Transform -- revisited Germano Caronni
- Re: Stream Cipher Transform -- revisited Terry L. Davis, Boeing Information & Support Services, Bellevue, WA
- Re: Stream Cipher Transform -- revisited Tatu Ylonen
- Re: Stream Cipher Transform -- revisited John Gilmore
- Re: Stream Cipher Transform -- revisited C. Harald Koch