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
participants (4)
-
chen＠intuit.com -
jimbell＠pacifier.com -
Scott Brickner -
Simon Spero