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]
