1994-07-27 - Re: XSplit & N/M alternatives

Header Data

From: adwestro@ouray.Denver.Colorado.EDU (Alan Westrope)
To: rarachel@prism.poly.edu
Message Hash: 691e5cc6d618202a6690bc60387b962d33ad86090da22d11b4a9b758384a6dd5
Message ID: <RHdDkaa0iMHR069yn@ouray.denver.colorado.edu>
Reply To: <9407271250.AA16759@prism.poly.edu>
UTC Datetime: 1994-07-27 15:24:55 UTC
Raw Date: Wed, 27 Jul 94 08:24:55 PDT

Raw message

From: adwestro@ouray.Denver.Colorado.EDU (Alan Westrope)
Date: Wed, 27 Jul 94 08:24:55 PDT
To: rarachel@prism.poly.edu
Subject: Re: XSplit & N/M alternatives
In-Reply-To: <9407271250.AA16759@prism.poly.edu>
Message-ID: <RHdDkaa0iMHR069yn@ouray.denver.colorado.edu>
MIME-Version: 1.0
Content-Type: text/plain


> Also, XSPLIT will produce N files of the same size as the original file you
> feed it.

I just glanced at the .doc and ran it once last night on my PC -- haven't
looked at the source -- but a possible application of this occurred to me
this morning.  The N files are binary, but it should be easy to restrict
them to ASCII using a command-line switch or a file for PRNG input, right?
Then they would be suitable for Internet (re)mailing.  (Concerns about
cryptographic integrity are irrelevant for my purposes.)

A remailer could receive, say, a 5k message, which might be ~4.5k after
peeling off that remailer's layer of encryption.  XSPLIT could then be
invoked to produce several ASCII files of identical size.  These bogus
files could be mailed to various remailers at the same time as the "real"
file, with a prepended instruction to send 'em to the bit bucket.  Of
course, latency would then have to be added before processing the "real"
file to defeat traffic analyis.  I'm probably missing something, but
it's a thought anyway...


Alan Westrope                  <awestrop@nyx.cs.du.edu>
__________/|-,                 <adwestro@ouray.denver.colorado.edu>
   (_)    \|-'                  finger for pgp 2.6 public key
"Silent, We the Empire Await, Trystero!" -- Pynchon (sorta...)





Thread