Re: [iaik-ssl] [iaik-jce] Java JCE 1.2.1 Spec - a danger for iaik??

["Stef Hoeben" <stef.hoeben@utimaco.be>]

cross-talk ;-)

---------------------- Forwarded by Stef Hoeben/Utimaco/BE on 09/28/2000
03:07 PM ---------------------------
Hi Stef,

iaik-jce rejected the following article. Perhaps you can send it to the
iaik
list, I am not subscribed there

---
Hello Stef, hello all,

> - BUT I think the only problem would be if the JCE would move into the
core
> classes: if the
> javax.crypto classes become a fixed part of each Java distribution,
> applications may be
> obliged to use them.


javax.* is, as far as I remember, meant as "additional, non-core" classes.
Loading of the original classes should therefore never be enforced by the
class loader as in the java.* tree. So you should always be able to
overload
these classes with your own implementation.

And even if not. E.g. Cryptix 3 used to have problems with the new Java 1.3
class loader. Cryptix 3 builds up on JCE 1.1 and implements therefore
classes
below java.*. Those could not be loaded anymore.

Solution: Move those classes into another package, e.g. javay.* or xjava.*,
as Cryptix 3.2.0 does it. Syntax changes slightly, so you have to adjust
your
sources, but this can be done even automatically. I did it
pseudo-automatically when changing to the new naming scheme, which needed
about half an hour for a not that small project.

Semantics do not change at all and compatibility problems did not occur
either. That would only happen if you interact with classes from the
original
java.crypto.* package and those classes implement "package private" (e.g.
default) methods. Cryptix 3.2.0 does interact that way with something in
java.security.*, but the package private problem does not occur. Any clean
room implementation of java(y).crypto.* would not have any of these
interactions at all.

It should even be possible to mock up a javax.crypto.*-lookalike in
javay.crypto that wraps an original javax.crypto provider seamlessly. So
you
could write your code for javay.crypto.* and use even any javax.crypto
provider.

Nevertheless, I do not think that Sun is able (or even wants) to force a
silliness like NSA compilant security providers. It would be like a
government which forces its citizens to leave their house keys at the local
thieves' meeting point while being on vacation.

Last remark: I for myself stay happy with my self-patched Cryptix 3.1.3. It
gives me RSA, it gives me 3DES, it runs on any JVM. I do not need more...
(Of
course, this is not an argument... ;-)

Ciao, Dirk
---

Ciao, Dirk

--
Dirk Hillbrecht         . +----------------------+ .
chitec OHG              . |     dh@chitec.de     | . Sent from
Vahrenwalder Str. 7/TCH . | http://www.chitec.de | .  office
30165 Hannover          . +----------------------+ .




--
Mailinglist-archive at http://jcewww.iaik.at/mailarchive/iaik-ssl/sslthreads.html

To unsubscribe send an email to listserv@iaik.at with the folowing content: UNSUBSCRIBE iaik-ssl