From: jimbell@pacifier.com (jim bell)
Date: Sat, 18 Nov 1995 06:46:12 +0800
To: Simon Spero <ses@tipper.oit.unc.edu>
Subject: Re: NSA, ITAR, NCSA and plug-in hooks.
Message-ID: <m0tGGn7-0008x9C@pacifier.com>
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. 
>
>The real issue would appear to be intent, though. If it's obvious that 
>the real intention for the hook is to allow encryption to be added, 
>the State department can jump on it. 

I'm not a programmer, but it seems to me that if the goal is to minimize the
"obviousness" of the provision for cryptography, the calling program could
call the called program (which might be an encryption program, maybe not)
and ask for a text header that is to be listed in a Windows-type window.
Thus, the calling program would not have any references to "encryption" or
"key" in its program or documentation; it would get that the first time it
calls the called program.  

BTW, one function which obviously  needs an additional argument to work is a
CRC program, in which the particular polynomial to be used must be
specified.  And I guess that a CRC is basically the same type of thing as a
hash function, too.