>I'm spending more and more of my time these days in the free software
>community (not all that big a leap for a cypherpunk). I'm seeing the
>"crypto integration" problem all over the place.
This is an issue of serious concern; it's really holding up the
adoption of encryption, particularly at the TCP/IP level.
An interesting model for how to get around the US regulations is what
Sun is doing with Java. Java 1.2 ships with pretty much everything you
need for strong, composable cryptography - big numbers, a key
management framework, digital signatures.
But they're following the letter of the US export regulations. Sun has
defined the Java Cryptographic Extensions, a decent API for doing
encryption. Bcause they are a US company they only ship a JCE
implementation to people in the US. But they've made it about as easy
as possible for folks outside the US to implement their own drop-in
replacements.
One interesting choice they've made is that, as near as I can tell,
they aren't even bothering to ship a 40/56 bit crippled version. If
you want crypto at all, you have to use Sun's JCE or get a non-US
alternative. So you can only get real crypto, not some useless junk.
I think that's probably the right idea - don't cave in to the US
regulations, just follow them the minimum you have to and make sure
it's easy for people outside the US to reimplement the parts you are
not allowed to ship.
I guess we have to wait and see how much Wassenaar complicates things.
[EMAIL PROTECTED]
. . . . . . . . http://www.media.mit.edu/~nelson/
