Interesting discussion! It would be cool if those who have done
extensive performance testing were to submit them as a patch to WSS4J,
preferably in unit test form with no Axis dependencies.
There's no doubt that WS-Security is slow, our own experiments show that
WS-Security is about 15x slower than HTTP/S. However, as someone with a
background in cryptography, I'd like to point out in the context of this
discussion that it's somewhat of a myth that public key crypto is
extremely expensive. For example, encrypting (or verifying) with RSA
using the typical exponent of 65537 is just a handful of multiplications
and modular reductions.
E.g. doing a speed test with openssl yields:
sign verify
rsa 1024 bits 0.003143s 0.000149s
(dsa doesn't have this advantage):
dsa 1024 bits 0.001390s 0.001673s
It's pretty plain from the figures that a PKC operation is around 3
milliseconds for the most expensive case, although I guess we don't have
the advantage of an optimized C++ crypto implementation in WSS4J. IMO
C14N (in the case of signature) and DOM are the main culprits for
performance as far as WSS4J is concerned, not PKC.
Dennis, you say that "I've also seen that WSS4J may canonicalize the
message unnecessarily, at least in some cases." - care to point out some
examples or submit a patch on this?
Colm.
-----Original Message-----
From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]
Sent: 12 October 2008 07:31
To: Werner Dittmann
Cc: jimmy Zhang; [EMAIL PROTECTED]; [email protected]
Subject: Re: WSS4J 1.5.4 Encryption Performance Question
Canonicalization is definitely a time hog, especially since it's done
using a DOM - and DOMs are expensive in terms of both memory and
construction time. I've also seen that WSS4J may canonicalize the
message unnecessarily, at least in some cases.
But it seems unlike that canonicalization would be the cause of Shawn's
performance hit in this case. Shawn said his performance was not
significantly effected by turning on signing of the username token, but
was effected by encrypting the username token. Signing is the part that
requires canonicalization, not encrypting.
My own tests of Axis2 performance with WS-Security turned on have given
much worse results than reported by Shawn, but I was looking at signing
and/or encrypting the entire message.
- Dennis
Werner Dittmann wrote:
> jimmy Zhang schrieb:
>> The latest performance reports point to canonicalization as the major
>> CPU eater...
>> that part needs to be virtually completely redone...
>
> Wow - never thought that :-). Unfortunately we cannot influence this
> part easily be changing the way how to encrypt/select keys. C14n is
> nearly always needed, at least for signature and for serialization
into
> the real message (XML stream).
>
> Regards,
> Werner
>
>> ----- Original Message ----- From: "Werner Dittmann"
>> <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Cc: <[email protected]>
>> Sent: Friday, October 10, 2008 11:58 PM
>> Subject: Re: WSS4J 1.5.4 Encryption Performance Question
>>
>>
>>> Shawn,
>>>
>>> the most expensive part during encryption (and in some cases also
>>> Signature) is the asymmetric encryption part. Several years ago (in
>>> the beginning of WSS4J :-) ) I did some performance tests to detect
>>> where time is lost.
>>>
>>> I assume you use the standard way to encrypt/decrypt data, thus the
>>> following process is used:
>>>
>>> - get information about the public key of the receiver (usually
using
>>> the receiver's x.500 certificate)
>>>
>>> - generate a random key that WSS4J uses to symmetrically encrypt the
>>> content, for example the SOAP body on in your case the user name
>>> token
>>>
>>> - encrypt this random key a using public key algorithm, for example
RSA
>>> (which public key algo will be used depends on the contents of the
>>> certificate)
>>>
>>> - build up the Security header.
>>>
>>> The step to encrypt the random key is the most expensive. Your
>>> configuration shows that you are using UsernameTokenSignature thus
you
>>> do not do a "real" Signature using a x.500 certificate bu a specific
>>> variant where data of the user name token is used to compute a
>>> signature.
>>> This explains why the signature processing is fast in your test
frame.
>>>
>>> During the tests I could speed up the public key processing by using
>>> another security provider - Apache JuiCE which is a Java JCE wrapper
>>> that uses openSSL as crpyto engine that gave me between 30-50%
better
>>> performance compared with bouncy castle.
>>>
>>> Thus to speed up this you may consider using keys that do not depend
on
>>> certificates - AFAIK there is also a way to send keys using user
name
>>> token, but this needs to be confirmed.
>>>
>>> Regards,
>>> Werner
>>>
>>> Shawn McKinney schrieb:
>>>> Hello,
>>>>
> <SNIP ---- SNAP>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
