# Re: Desperately seeking JDK1.1.x Signature help!!!

Mike Burati (burati@pubweb.net)
Thu, 25 Jun 1998 14:48:06 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Previous message: Andy Martinez: "A query on Client Application"
- Maybe in reply to: Mike Burati: "Desperately seeking JDK1.1.x Signature help!!!"

    Message-Id: <3.0.1.32.19980625144806.00f04d50@mail.pubweb.net>

    Date: Thu, 25 Jun 1998 14:48:06 -0400

    To: java-security@web4.javasoft.com, JSERV-INTEREST@javasoft.com

    From: Mike Burati <burati@pubweb.net>

    Subject: Re: Desperately seeking JDK1.1.x Signature help!!!

You're not going to believe this... I figured out most (possibly all)
of what was causing the pathetic response time I saw yesterday...

For yucks, I separated the user interaction servlets from the job
processing servlet, by doing the equivalent of JWS addservice manually
(I haven't had good luck using the tool to do it). Even in separate
virtual machines, running on separate ports, the gui generation servlets
would hang for 10 minutes while trying to sign the message, before posting
it to the job processing servlet. Bewildered, I tried to show this to
a coworker, but this time running the browser (Netscape 4.01) on their
system instead of mine since I was at his desk. Amazingly enough, this
time it took a couple seconds to sign the message, instead of 604.

So, I went back to my system (NT4.0 Wkstn) and tried it again, and sure
enough it hung during the signing again. So, I brought up task manager
and found out that the CPU was pegged at 100%. Bringing up the processes
display and sorting by CPU, netscape.exe was using up 98% constantly, and
the two jre processes were getting next to nothing. Iconizing netscape
(to get rid of the stupid dynamic N, and the sliding Cylon-like in progress
bar), and it was still using 96% (probably trying to see if it could draw...).

Hitting the stop button on netscape, within seconds, the servlet finished
signing the message, posted it to the job processor servlet, which also
verified the 1st signature and re-signed it with it's own key in a matter
of seconds...

So, what's the moral of the story? Don't do this on NT4.0 Wkstn. I've
heard that NTWkstn gives priority to Windows based processes over server
based processes (those without a window context?), whereas NTServer gives
priority to server processes over Windows based processes. Luckily, this
is just my development/test system. Our production version runs on our
Solaris 2.6 box...

>Date: Wed, 24 Jun 1998 17:51:41 -0400
>From: Mike Burati <burati@pubweb.net>
>Subject: Desperately seeking JDK1.1.x Signature help!!!
>...
>Ok, my brain is fried, otherwise I'd probably be able to figure out
>some of this myself, but I need advice...
>
>We have been developing a JAVA based solution that's built around
>the Java Web Server and servlets. Since our system will need to
>integrate with other web/http based systems out there, http/https
>is the obvious choice to base our transport on too. We use the
>SSL built into JWS for privacy, and we're trying to use the built
>in DSA support in JDK1.1.x to sign/verify our messages from one
>service to another.
>
>BEFORE anybody answers, we CANNOT use JDK1.2, since it's not released
>yet, and we're piloting this to customers now. We rely on Sun's JWS,
>which is not even qualified on JDK1.1.6 yet, nevermind JDK1.2, so
>we're stuck with JDK1.1.4/JDK1.1.6 for a while. Also, we are not
>using the sun.security internal calls, we are using the public
>Keypair generator classes and Signature class/methods only.
>
>This has all been working fine up until this afternoon. I generate
>keys in a standalone utility, so the above SecureRandom bug hasn't
>been affecting us. Up until this afternoon, signing messages up to
>and through 300K was taking a few seconds (5?) at most. I just
>configured another piece into my test system (so I have two servlets
>signing messages, instead of one signing/one verifying). Even though
>Only one is signing/verifying at a time, the signing of 170K bytes is
>now taking 604 to 605 seconds *EVERY TIME*. What could cause this?
>
>Is Signature.sign() using the above SecureRandom class in a way that
>would cause this looping bug?
>
>I upgraded my Java Web Server1.1 from 1.1.5 to 1.1.6 based on the
>above claimed fix, and it's still agonizingly slow!
>
>HELP!. Again, JDK1.2 is not an answer. They'll make us rewrite
>everything in C++ before letting us wait for 1.2 to become widely
>used and supported by JWS. What are other's experiences with
>signing/verifying data in moderately loaded services with JDK1.1.x???
>
>We've had good experiences with JWS and it's SSL support, and
>the DSA signature capabilities of JDK1.1.x up until this point...
>
>Thanks in advance,
>..Mike

- Previous message: Andy Martinez: "A query on Client Application"
- Maybe in reply to: Mike Burati: "Desperately seeking JDK1.1.x Signature help!!!"