Re: NSA, ITAR, NCSA and plug-in hooks.

>jim bell writes:
>>>I think it's 121.1, Category XIII paragraph (b) item (5):
>>>"Ancillary equipment specifically designed or modified for paragraphs (b)
>>>(1), (2), (3), (4) and (5) of this category;"
>>
>>Question:  What makes computers in general NOT describable by such a
>>paragraph?!?
>
>The referenced paragraphsdescribe cryptographic hardware, software and
>technical data.  Computers in general are not "specifically designed"
>as cryptographic equipment.

Great!  Then you must merely ensure that there is at least one
(non-encryption) program around that can use the same hooks.

jim bell writes:
>>jim bell writes:
>>>>I think it's 121.1, Category XIII paragraph (b) item (5):
>>>>"Ancillary equipment specifically designed or modified for paragraphs (b)
>>>>(1), (2), (3), (4) and (5) of this category;"
>>>
>>>Question:  What makes computers in general NOT describable by such a
>>>paragraph?!?
>>
>>The referenced paragraphsdescribe cryptographic hardware, software and
>>technical data.  Computers in general are not "specifically designed"
>>as cryptographic equipment.
>
>Great!  Then you must merely ensure that there is at least one
>(non-encryption) program around that can use the same hooks.

The problem is that the non-encryption program must use the same
interface as the encryption program.  Text compression is often cited
as an example of a non-encryption program that can use the same hooks
as a compression program, but there's a key difference:  the text
compressor *doesn't* need a key.

The encryption tool would have an interface like
    Boolean (*)( DataSource, DataSink, void*);

A compressor written to the same interface would never need to touch
that third argument.  Therefore, the second argument is "specifically
designed" to permit an encryption tool to be used.

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.

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.

> 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