Re: Stream Cipher Transform -- revisited
"C. Harald Koch" <chk@border.com> Wed, 31 July 1996 14:47 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa12788; 31 Jul 96 10:47 EDT
Received: by relay.hq.tis.com; id KAA14794; Wed, 31 Jul 1996 10:50:15 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1) id xma014737; Wed, 31 Jul 96 10:49:27 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA27557; Wed, 31 Jul 96 10:48:56 EDT
Received: by relay.hq.tis.com; id KAA14703; Wed, 31 Jul 1996 10:49:19 -0400
Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma014677; Wed, 31 Jul 96 10:49:00 -0400
Received: by janus.border.com id <18436-2>; Wed, 31 Jul 1996 10:50:21 -0400
Message-Id: <96Jul31.105021edt.18436-2@janus.border.com>
To: John Gilmore <gnu@toad.com>
Cc: Germano Caronni <caronni@tik.ee.ethz.ch>, 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
References: <199607310913.CAA23906@toad.com>
In-Reply-To: gnu's message of "Wed, 31 Jul 1996 05:13:40 -0400". <199607310913.CAA23906@toad.com>
From: "C. Harald Koch" <chk@border.com>
Organization: Border Network Technologies Inc.
Phone: +1 416 368 7157
X-Uri: <URL:http://www.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2; hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm; z:NJ7pss)l__Cw+.>xUJ) did@Pr9
Date: Wed, 31 Jul 1996 10:51:15 -0400
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In message <199607310913.CAA23906@toad.com>, John Gilmore writes: > I advise against making *any* design decision that trades off security > or privacy for MIPS Agreed, with an explanation. :-) There are two points on the performance curve worth considering; slow hardware is one, but high-speed/high-volume data streams are another. Take a real-time, broadcast-quality, full-motion M-JPEG stream, for example... I fully support continuing development for supporting stream ciphers within IPsec. However, to agree somewhat with John, these should be *optional* transforms. -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change.
- 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