See small comment inline :-) Werner
<SNIP --- SNAC> > 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. Werner: Well, WSS4J uses standard Jave JCE interfaces only and of course we have an openSSL crypto implementation ;-) - it's called JuiCE, a "sleeping" Apache Incubator project. JuiCE is a Java JCE that uses openSSL as crypto backend. Tests have shown that the big number processing (i.e. RSA et al) is about 3-4 times faster that with BouncyCastle. Overall WSS4J processing was improved by 30-40% 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
