[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    RE: [dev-crypto] Problem with time used to instantiate RSA Cipher
From:       "Michael Saladin" <msaladin () e3ag ! ch>
Date:       2008-10-22 7:26:39
Message-ID: 1F6AD5491A0C6249A07D9AAC43036C99599415 () exchserver ! ch ! e3ag ! net
[Download RAW message or body]

Thanks a lot for all your help, it really has something to do with the
Java VM that I was using. 

I develop with Java 1.5_05, and there the time used to call
Cipher.getInstance() takes about 2'500 millis the first time. But when I
switch to VM 1.5_16 or one of the 1.6, I get the result after about 600
millis or after 450 millis (1.6_10). This is much more better. 

So shame on me, I should never have used such an old Java on my
development system.

Greetings
Michael 

-----Original Message-----
From: David Hook [mailto:dgh@lockboxlabs.com] 
Sent: Mittwoch, 22. Oktober 2008 00:47
To: Michael Saladin
Cc: dev-crypto@bouncycastle.org
Subject: Re: [dev-crypto] Problem with time used to instantiate RSA
Cipher


I can't really think of anything BC related that would cause this.

One thing you could try to isolate where the time is going is calling 

MessageDigest.getInstance("SHA-1", "BC");

This will invoke the provider via the JCA. My guess is you'll find this
is a lot quicker. What's probably happening is that the JCE validation
of the jar and algorithm is what's churning the time. Moving the
provider jar into jre/lib/ext might also improve things.

Regards,

David

On Tue, 2008-10-21 at 16:14 +0200, Michael Saladin wrote:
> Hi all,
> 
> We have a software that consists of a GUI (for the definition of 
> something like "actions", and those definitions are stored in a
> database) and a background agent (daemon) that normally has no 
> interaction with any user (the agent is used to execute those actions 
> that were defined earlier in the GUI).
> 
> An enduser makes definitions in the GUI (which stores these 
> definitions in the DB) and then can intiate an action out of those 
> definitions. No
> problem: The user authentication and authorisation are all done in the

> GUI (and in the database).
> 
> We provide another way to initiate an action that can be automated or 
> invoked on the command-line: The user can export the definitions from 
> the DB into a file, and then use a command-line-tool to execute those 
> actions according to the exported file (no connection to the DB is 
> necessary).
> 
> The last part seems to be of a problem. We want to make sure that the 
> file has not been tampered with, and we want to allow the customer to 
> use a company private key that those exported files cannot be traded 
> with other customers. Therefore, each exported file starts with a 
> PREFIX and then contains the definitions (CONTENT).
> 
> When exporting: 
> 1) The user has to provide a password,
> 2) We create a HASH about the CONTENT
> 3) We combine the HASH of the password and the HASH of the content
> 4) We sign the combined HASH with the companys PRIVATE key
> 
> When the user then invokes the command-line-tool (a Java tool), the 
> java tool reads the file and then creates the combined HASH of the 
> provided password, of the rest of the file (CONTENT), and then checks 
> if this is really what is written in the PREFIX of the file. For this,

> it checks the signature (decrypts the PREFIX with the public key). 
> That works quite good.
> 
> We experienced a problem when we use the SUN JCE. The problem is that 
> our software runs on AIX and ZOS/USS as well (besides Windows, Solaris

> and Linux), and there is no SUN VM on those systems, therefore no SUN 
> JCE. With the IBM JCE, it did not work. I suppose that the IBM JCE 
> provides RSA, but with different padding algorithm, or with different 
> block sizes. I did not find any way to export a file with the SUN VM 
> and then execute the file with the command-line tool running with the 
> IBM VM.
> 
> The next thing I did try is to use  BouncyCastle. This works great, 
> but I need to deliver the external JAR file (1.6 MBytes) with the 
> software and I need to make sure that the user has the correct version

> of Java for the JAR file.
> 
> This would be possible, but it takes about 2'500 millis just for
> Cipher.getCipher() to return. This is too long for a
command-line-tool.
> 
> I tried to find out what takes so long and tried to compile 
> bouncycastle to be able to insert System.outs to find out where the 
> time is lost. I can compile it and create a JAR file, but the JAR file

> is not signed so I cannot use it. When I sign it with a self-signed 
> cert, I get an error telling me that this is not possible (Caused by:
> java.util.jar.JarException:
> file:/C:/apps/tgrid/lib_java/bcprov-jdk15-142b01.jar is not signed by 
> a trusted signer).
> 
> So I'm a little stuck here. Can anybody explain to me what takes 2'500

> millis at the start when I'm invoking:
> 
> Cipher cipher1 = Cipher.getInstance("RSA", "BC");
> 
> By the way, it takes almost the same amount of time when I'm invoking 
> another cipher algorithm, e.g. DES or IES. But once I have invoked 
> getCipher for one algorithm, it is very fast for a subsequent
algorithm.
> 
> 
> This would be no problem for a server daemon or process running in the

> background and only have an initialization once, but a user assumes 
> that a command-line-utility is fast and retruns an answer promptly. 
> 2.5 seconds is too long for an ordinary user just to have invoked a 
> command with no reply from the program.
> 
> Any ideas/help is appreciated.
> Thank you.
> Michael
> 
> 
> 
> 
> 
> 
> 



[prev in list] [next in list] [prev in thread] [next in thread]