This also might be helpful: http://lis.fh-aargau.ch/nicola/pub/WSS4Jperformance.pdf
-----Original Message----- From: jimmy Zhang [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2008 12:53 PM To: Werner Dittmann Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: WSS4J 1.5.4 Encryption Performance Question http://www.w3.org/2007/xmlsec/ws/papers/06-zhang-ximpleware/ ----- Original Message ----- From: "Werner Dittmann" <[EMAIL PROTECTED]> To: "jimmy Zhang" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[email protected]> Sent: Saturday, October 11, 2008 1:19 AM Subject: Re: WSS4J 1.5.4 Encryption Performance Question > 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] _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
