From: chen@intuit.com (Mark Chen)
Date: Sun, 19 Nov 1995 08:57:45 +0800
To: ses@tipper.oit.unc.edu (Simon Spero)
Subject: Re: NSA, ITAR, NCSA and plug-in hooks.
In-Reply-To: <Pine.SOL.3.91.951116161656.19526G-100000@chivalry>
Message-ID: <9511170143.AA07316@doom>
MIME-Version: 1.0
Content-Type: text/plain



> On Thu, 16 Nov 1995, Scott Brickner wrote:
> > 
> > You'd need a program which not only *accepted* the additional parameter,
> > but also *needed* the second parameter.  I confess I have some difficulty
> > thinking of one.
> 
> It's not too hard to think of a compression scheme that needs extra 
> information to be passed from client to server; the obvious example is 
> some sort of dictionary compression with external dictionaries (can be 
> very effective for short messages where LZW etc never get a chance to get 
> going). 
> 
> Another, more likely case, is where the object could have been compressed 
> by several schemes, and a scheme ID is needed to determine which 
> alogorithm to use. 

But the problem is more on the application side than on the library
side.  If necessary, you can simply design the plug-in crypto function
to regard the first n bytes of the input buffer as a key.  On the
other hand, how do you explain why your application (for which you're
seeking export approval) is generating keys in the first place?  And
what's this other piece of code over here that just sits around and
captures mouse movements at random intervals? :)

   - Mark -


--
Mark Chen 
chen@intuit.com
415/329-6913
finger for PGP public key
D4 99 54 2A 98 B1 48 0C  CF 95 A5 B0 6E E0 1E 1D