Mike,
To give you a bit more background, we have seen that the bulk of the processing time (about 99%) is spent in X931KeyGenerator.java in this while loop:
// The condition for the while loop in English is // while ( ( gcd(e,p-1)!= 1 ) or ( p is not a prime) ) while ( ( ( ( publicExponent.gcd ( candidate.subtract( BigInteger.ONE ))).compareTo( BigInteger.ONE))!= 0 ) || (!isProbableX931Prime( candidate )) ){
candidate = candidate.add( product );
}
That innocent looking code can take anywhere up to 40 seconds, depending on the input... Could you clarify a bit what the intent of that code is? Do you think that particular bit could be optimized in some way? Or does the specification for X9.31 key generation inherently make for costly implementations?
(for what it's worth I can't seem to find any freely available copy of that spec on the web?)
- ian.
On Jan 24, 2008, at 12:56 PM, Valery Kokhan wrote: Hi Mike,
I was playing for a while with your implementation of key pair
generator and as I can see this process may take even longer
then 40 seconds in my environment depending on the input parameters
(master key and RP URI).
I considered using 1024 key pairs as an option to improve performance
but I noticed that regardless from the fact that cardspace tech refs
specify that to sign security tokens either 1024 or 2048 keys could be
used current implementation of key pair generator could generate key
pairs of 2048 size only and throws an exception otherwise.
Is this desired behavior or a bug?
From my understanding if we use key pair of smaller size we could
improve performance significantly - in my environment when generation
of 2048 key pair takes about 30 seconds then generation of 1048 key
pair takes about 2,5 seconds only for the same input parameters.
Can we change current implementation to generate/use key pair of
smaller size?
--
Thanks,
Valery
Saturday, January 19, 2008, 1:54:43 AM, you wrote:
Brian,
We are hoping to extend the card store to cache the generated key pairs for
each RP so the key gen doesn't need to happen each time a card is used (it
would only happen the first time for each RP). This is expected to be on
the agenda for the F2F.
I have not seen this process take longer than 8 seconds, but even that is
too long. I am not sure why you are seeing 5X that.
Regards,
Mike
Brian Walker <BWalker@xxxxxxxxxxxxx> wrote on 01/18/2008 10:33:44 AM:
Hi Mike - I understand you on travelling this week - but wanted to
highlight this question to you. We are working to improve card
selector performance and have a major issue with the key generation
process.
Any insight and direction of what we can try to improve would be
most appreciated.
Thanks in advance....Brian
-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
bounces@xxxxxxxxxxx] On Behalf Of Valery Kokhan
Sent: Thursday, January 17, 2008 8:08 AM
To: Michael McIntosh
Cc: Higgins (Trust Framework) Project developer discussions
Subject: [higgins-dev] createPersonalRequest performance problem
Hi Mike,
We are trying to improve performance of our web based identity
selector and right now the biggest problem we have is with the
performance of TokenRequestFactory.createPersonalRequest sts method.
It looks like single call to this method may take up to 40 seconds!
And about 99% of this time is taken by key pair generation method.
I was looking at the implementation and it looks like it follows MS
specification precisely and I have no idea how it could be improved.
Do you have any ideas how to improve the performance of
TokenRequestFactory.createPersonalRequest sts method?
--
Thanks,
Valery
[attachment "PCardGetTokenObject.html" deleted by Michael
McIntosh/Watson/IBM] [attachment "ATT00001" deleted by Michael
McIntosh/Watson/IBM]
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
|
