[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Fw: Re[2]: FW: [higgins-dev] createPersonalRequest performance problem
|
Forwrding this on behalf of Suresh (bounced to the list since he is not a
member). Suresh wrote the code that was contributed for Key Generation.
----- Forwarded by Michael McIntosh/Watson/IBM on 01/24/2008 07:45 PM -----
Suresh N
Chari/Watson/IBM
To
01/24/2008 07:36 Michael McIntosh/Watson/IBM@IBMUS
PM cc
"Higgins (Trust Framework) Project
developer discussions"
<higgins-dev@xxxxxxxxxxx>, Ian
Hummel <hummel@xxxxxxxxxxxxx>,
Valery Kokhan
<vkokhan@xxxxxxxxxxxxxx>
Subject
Re: Re[2]: FW: [higgins-dev]
createPersonalRequest performance
problem(Document link: Michael
McIntosh)
Mike and Ian
The loop is essentially the heart of the key generation process. It
basically tests candidates one at a time to find one that is prime and
which can be used in RSA (e and (p-1) are relatively prime). The costly
step is the test isProbableX931Prime() which runs a number of tests
involving exponentiation.
Note that in general key generation is somewhat costly even if you run
native code with hand tuned assembly for key routines.
On top of this the X9.31 spec. adds some onerous tests, checks and
conditions to the process.
HTH
-Suresh
Michael McIntosh/Watson/IBM wrote on 01/24/2008 07:26:40 PM:
> Ian Hummel <hummel@xxxxxxxxxxxxx> wrote on 01/24/2008 01:14:42 PM:
>
> > 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?
>
> The MSFT spec makes it very clear that "input regeneration is a
> potentially unlimited process. In other words, it is possible that
> regeneration must be performed more than once. In theory, one may
> need to regenerate input parameters many times before a key that
> meets all of the requirements can be generated."
> >
> > (for what it's worth I can't seem to find any freely available copy
> > of that spec on the web?)
>
> You will need to purchase the specification, it is not free.
>
> I suggest that we move the RP Identifier, PPID, and Key Pair
> Generation functionality to a new configurable component. If you'd
> like to create an optimized alternative implementation that is
> platform specific (calls out to native code) you will then be free to do
so.
>
> >
> > - 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
