On Thu, 2 Dec 1999, Ron Rivest wrote:
> Here's a thought exercise:
>
> What happens if someone applies for an export license for a Java
> Virtual Machine, which he intends to use as an "encryption routine"?
> The idea (which is not new) is that a Java program (Java byte code)
> would be the "key" for the encryption. It specifies how to turn
> the input message into the output plaintext. Thus, the VM is doing
> the encryption work as specified by the byte-coded "key".
You can try that if you want, but all you'll succeed in doing is in making
the export regs more internally consistent and detailed, not in making
them any less stupid.
I would like to call everyone's attention to the following:
from http://java.sun.com/aboutJava/communityprocess/withdrawn.html
Withdrawn Java Specification Requests
The following Java Specification Requests (JSRs) have
been withdrawn from the Java Community Process for
the reasons stated.
JSR-000028 Java SASL Specification
Withdrawn 1999.11.05 before work began because
it describes a cryptographic system and/or a
crytpographic framework whose implementation
would be subject to U.S. Export Licensing
requirements.
JSR-000027 Java Cryptography Extension 1.3
Withdrawn 1999.11.05 before work began because
it describes a cryptographic system and/or a
crytpographic framework whose implementation
would be subject to U.S. Export Licensing
requirements.
The means that there will be no crypto shipped with the jdk in the future,
period. I say this is actually a good thing. Why? Because the JCE is a
piece of crap. It's interfaces were designed based on a clumsy engineering
hack to get around the old export regs. Then they changed the regs to ban
crypto shaped holes, so the JCE is now not exportable, but it's still a
piece of crap.
To all engineers of the world, I have a plea: don't try to use bad
engineering to get around legal problems. It won't work. Use legal things
to fix legal problems. Use engineering to fix engineering problems. Don't
mix the two.
And please, please DON'T use a provider based API for crypto. I know
you're all used to it, but it's a giant sucking security hole, and
unproductive to deal with on a daily basis. Use a factory design pattern
to produce new instances, and a naming service if you absolutely must be
able to swap in new implementations at link or runtime, but whatever you
do, don't give in to your emotional attachment to the old way. It really
does suck.
-Bram
