Home > Archive > Java Security > March 2008 > crypto with jce / without jce
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
crypto with jce / without jce
|
|
| renntier08 2008-03-16, 7:50 pm |
| Hello, I am new to this forum and my English is not very well. I have
the following problem. I wish to use unlimited cryptography within an
applet. I know, if I want to use unlimited crypto I have to install
the unlimited jurisdiction policy files. Because mostly the JRE is
installed under c:\programm files, where a normal user would not have
the right to write, it is not very convenient to ask an admin for
every workstation to install the unlimited jurisdiction policy files.
Is there anyway to use unlimited crypto without touching the clients
JRE?!?!
Is it possible to install the unlimited jurisdiction policy files in
another location on client at runtime???
Maybe I can use an alternate JCE (BC or GNU)? But how? I think I can
not install a new javax.crypto* from an applet? Maybe it's possible to
user another packet name?
Or is it possible to use the cipher functionality of a provider
outside the JCE?
Have somebody had the same problem before? Any answer is very welcome!
Regards from Berlin!
| |
| Roedy Green 2008-03-24, 7:35 pm |
| On Sun, 16 Mar 2008 07:04:18 -0700 (PDT), renntier08
<wookietrainer@googlemail.com> wrote, quoted or indirectly quoted
someone who said :
>
>Is it possible to install the unlimited jurisdiction policy files in
>another location on client at runtime???
If you wanted to do it manually, what would it do?
1. it would download something from Sun.
2. You would execute the download.
3. you would type into the installer to tell it where to go.
If I were tackling this, first I would scour the docs of the installer
to see if you could control it with command line switches. Then all
you need do is spawn it with exec from a signed applet.
Failing that I would look at the Robot class to see if it lets you
remotely control such an installer.
Failing that, I would look at the Windows API to see if I could
control another app, simulating a user. Then I would write JNI to let
me at that API from Java.
Failing that, I would install the package and see just what files it
puts where, and what it does to the registry. I would then write my
own installer that duplicated that, not using Sun's installer at all.
Failing that, I would have a look at The Transporter, an encryption
package without any restrictions on it no batter how many bits you put
in your key, that does not require JCE.
see http://mindprod.com/products1.html#TRANSPORTER
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
| |
| Maarten Bodewes 2008-03-30, 10:09 pm |
| renntier08 wrote:
> Maybe I can use an alternate JCE (BC or GNU)? But how? I think I can
> not install a new javax.crypto* from an applet? Maybe it's possible to
> user another packet name?
Nah, if you use the JCE, you will have to put up with the restrictions.
>
> Or is it possible to use the cipher functionality of a provider
> outside the JCE?
>
Well, you could just copy the BC code that does the encryption and use
that. You won't be able to use the JCE as you would like to do, but BC
cryptography works fine without the JCE wrapper. Just call the methods
directly.
The JCE restrictions are pointless really, and hopefully they will
removed soon. The GPL'ed Java should fix that, fortunately.
Regards,
Maarten
|
|
|
|
|