> Certain countries -- most notably the US -- consider any software with a > "crypto-shaped hole" in it to be equivalent to crypto software for > purposes of export controls; the buzzword is "enabling technologies". Any > code that is there solely or primarily to support use of cryptography is > covered. Whether "actual cryptographic code" is included or not does not > make much of a difference to export status. As it looks now, "enabling technologies" are not only considered equivalent but in fact "stronger" than actual encryption software. See the reasoning in <URL:http://java.sun.com/products/jce/jce121_faq.html#FewerRestrictions> (Which matches technical reality. Unfortunately, one is tempted to say.) > The only way to avoid this is to provide a more general-purpose interface > that clearly has other uses (i.e., other uses are actually implemented, > not just talked about). That's quite a bit harder to do. Which is why I was about to write a RFC for a "general data transform API" and provide a compression algorithm as an example some time ago. I gave up on that when discovering that the existing crypto API _very_ closely matched my thoughts. Hmmm... Olaf - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
