You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Werner Dittmann <We...@t-online.de> on 2004/02/27 20:56:15 UTC
Re: Using XML security slows down the Axis Call
Some time ago (6 weeks or so) I did some performance measures (WSS4J has
timing logs build in) and we see here that Verification/Signature
is real time consuming, followed by public KEy encryption, followed
by symmetrical encryption....this ordering comes with no surprise.
Only the real time consumed is quite high.
Regards,
Werner
----- Original Message -----
From: "Anderson Jonathan" <an...@bah.com>
To: <se...@xml.apache.org>
Sent: Friday, February 27, 2004 7:23 PM
Subject: RE: Using XML security slows down the Axis Call
> We're using Apache's WSS4J, which uses XML-Security under the covers.
We're
> seeing similar orders of magnitude.
>
> Also, just FYI - there is an XML-Users mailing list in addition to the
> XML-Dev list. I know the XML-Dev guys like to keep the user traffic down.
> :)
>
> -Jon
>
> -----Original Message-----
> From: Erwin van der Koogh [mailto:vdkoogh@apache.org]
> Sent: Friday, February 27, 2004 10:57 AM
> To: security-dev@xml.apache.org
> Subject: Re: Using XML security slows down the Axis Call
>
>
> > But I am very much worried about the PERFORMANCE. After
> > "org.apache.xml.security.Init.init()" of xml security is called (during
> > authentication), calling Call.invoke method takes more time. The
> > difference is in the order of multiples of 5.
>
> Verifying signatures is a very expensive operation.. Back in the days when
> we were extremely serious about performance it could take up to a second
on
> a P100 and that was just the verify.. With XML-DSig there's a whole bunch
> of extra parsing and verification to be done, slowing it down even more.
Of
> course computers are a lot more powerful, but I think they pretty much
keep
> up :)
>
> > Have any of you faced this problem? Why
> > org.apache.xml.security.Init.init() slows down the Call.invoke()
>
> Is the performance really Init.init()? Cause that might take a while, but
> that should only be one once. Subsequent calls to this method should
return
> instantly.
>
> Erwin
>
>
RE: Using XML security slows down the Axis Call
Posted by Scott Cantor <ca...@osu.edu>.
> You're saying you need Linux support from PKCS11 hardware devices,
and
> haven't found any?
Rainbow is a fairly good example. They have a working PKCS11 library for
Linux but they won't give it to you without some real begging and no
support. More importantly, it turns out in Rainbow's case they single thread
access to their cards, so the potential gains for Java are nicely throttled
anyway. Something to keep in mind, since they'll happily sell you a higher
end card that just has multiple processing units on it that will go unused
by any one process. ;-)
> We're just now beginning to explore hardware
> acceleration options for Java JCE, and I've heard rumblings of great
> performance gains using PCI cards such as Eracom's ProtectServer line.
The
> line I was sold was "all you do is point your VM at the new JCE provider
in
> your java.security - it's just that easy."
It's something you can get working, but it's definitely not a fully portable
solution. Windows and Solaris tend to be very well supported, Linux
definitely less so. Of course, check with the company, but also be prepared
for clueless marketing reps and a lot of half-true information. It's
definitely not something you just drop in unless you do your homework first.
Also, it's normally the case that the hardware alone will not give you Java
support. You need a JCE that can talk to your card. Sometimes the hardware
company can sell you one, plus there are other companies like Phaos that
support PKCS11. But that's usually a $2000+ investment + maintenance on top
of the card.
What you'll tend to find is Linux is well-supported for OpenSSL engine use,
but not for PKCS11. So I eventually felt that if I wanted a decent amount of
flexibility for myself, the OpenSSL route was less of a lock-in. I figure I
can run on Windows with Java 1.5 and the PKCS11 support there, and use the
OpenSSL bridge on Linux, and keep my software costs at zero.
Feel free to let me now how it goes. We're in the process of growing our
install base for Shibboleth and eventually campuses are going to run up
against the need to scale the signing operations, so we're collecting
possible solutions we can document for people.
-- Scott
RE: Using XML security slows down the Axis Call
Posted by Anderson Jonathan <an...@bah.com>.
Scott,
You're saying you need Linux support from PKCS11 hardware devices, and
haven't found any? We're just now beginning to explore hardware
acceleration options for Java JCE, and I've heard rumblings of great
performance gains using PCI cards such as Eracom's ProtectServer line. The
line I was sold was "all you do is point your VM at the new JCE provider in
your java.security - it's just that easy."
I didn't think to ask about any OS specific device drivers that might be
required. Any experiences? And yeah - the OpenSSL bridge approach sounds
very cool indeed. Hats off and good luck.
-Jon
-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu]
Sent: Friday, February 27, 2004 2:55 PM
To: security-dev@xml.apache.org
Subject: RE: Using XML security slows down the Axis Call
> Some time ago (6 weeks or so) I did some performance measures (WSS4J has
> timing logs build in) and we see here that Verification/Signature
> is real time consuming, followed by public KEy encryption, followed
> by symmetrical encryption....this ordering comes with no surprise.
>
> Only the real time consumed is quite high.
In our SAML authority, we've found it totally unscalable, and some of our
contributors have been working with native code to bridge the JCE interface
to OpenSSL. This is nice mostly because other hardware solutions based on
PKCS11 don't get a lot of vendor support on anything but Windows and
Solaris, and OpenSSL's engine layer does. JDK 1.5 has the PKCS11 support,
but it doesn't do much good if you can't get the libcryptoki you need.
The speeds up are dramatic, and pretty much suggest Java's unusable for this
sort of thing, which is not a surprising conclusion to me.
Note I'm talking about supporting many signatures a second. If you don't
need that, Java's fine.
-- Scott
RE: Using XML security slows down the Axis Call
Posted by Davanum Srinivas <di...@yahoo.com>.
understood. will kick the tires when i get a chance next week.
thanks,
dims
--- Scott Cantor <ca...@osu.edu> wrote:
> > Can you please post your config.xml?
>
> I don't actually have it configured in or tested yet, I was busy playing
> with Phaos' JCE while they were building this thing. I'll ask them to give
> me a copy.
>
> I can tell you more or less what's involved. You just go down into the
> section under providers and add a reference to the provider class
> (edu.internet2.middleware.nativejce.Provider) and assign it a shorthand
> name. Then you stick in a reference to the provider at the top of the
> various algorithm lists below.
>
> Looks like they've implemented MD5, SHA1, SHA1withRSA and RSA (which I think
> doesn't work because the jar isn't signed).
>
> -- Scott
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: Using XML security slows down the Axis Call
Posted by Scott Cantor <ca...@osu.edu>.
> Can you please send me the details of EXACTLY what kind of
> jar signing needs to be done to get the
> RSA stuff working? I dug/googled a bit but could not find the details.
Here's the relevant pointer:
http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/HowToImplAJCEProvider
.html
Basically either Sun or IBM's code signing CA is trusted to sign a JCE
provider.
Step 5a in that document describes the process for Sun.
-- Scott
RE: Using XML security slows down the Axis Call
Posted by Davanum Srinivas <di...@yahoo.com>.
Scott,
Can you please send me the details of EXACTLY what kind of jar signing needs to be done to get the
RSA stuff working? I dug/googled a bit but could not find the details.
thanks,
dims
--- Davanum Srinivas <di...@yahoo.com> wrote:
> I just downloaded OpenSSL, compiled nativejce.dll (MSDEV on WIN32) and am able to run the tests
> (I
> had to comment out System.loadLibrary("crypto") calls in 2 java files and keep just the
> System.loadLibrary("nativejce") calls). Here's the output from the test
>
(http://marsalis.internet2.edu/cgi-bin/viewcvs.cgi/NativeJCE/java/tests/edu/internet2/middleware/nativejce/CryptoTests.java)
>
> Thanks,
> dims
>
> C:\sf\NativeJCE>cat TEST-edu.internet2.middleware.nativejce.CryptoTests.txt
> Testsuite: edu.internet2.middleware.nativejce.CryptoTests
> Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 9.844 sec
> ------------- Standard Output ---------------
> Native Start: 1078126144057
> Native Stop: 1078126144057
> Sun Start: 1078126144057
> Sun Stop: 1078126144057
> Native Start: 1078126144078
> Native Stop: 1078126144078
> Sun Start: 1078126144078
> Sun Stop: 1078126144078
> Native Start: 1078126144088
> Native Stop: 1078126144088
> Sun Start: 1078126144088
> Sun Stop: 1078126144088
> Native Start: 1078126144088
> Native Stop: 1078126144088
> Sun Start: 1078126144088
> Sun Stop: 1078126144088
> Sun sig Start: 1078126148644
> Sun sig Stop: 1078126148704
> Native sig Start: 1078126148704
> Native sig Stop: 1078126148714
> Sun sig Start: 1078126149635
> Sun sig Stop: 1078126149666
> Native sig Start: 1078126149666
> Native sig Stop: 1078126149676
> Sun Sig: 100 sigs in 2694 ms = 26.94 ms/run
> Native Sig: 100 sigs in 851 ms = 8.51 ms/run
> ------------- ---------------- ---------------
>
> Testcase: testMD5 took 0.17 sec
> Testcase: testMD5_2 took 0 sec
> Testcase: testSHA_1 took 0.01 sec
> Testcase: testSHA_1_2 took 0 sec
> Testcase: testRSA_1 took 3.204 sec
> Testcase: testRSA_2 took 0.941 sec
> Testcase: testSHA1withRSASignature took 0.501 sec
> Testcase: testSHA1withRSASignature_2 took 0.952 sec
> Testcase: testSHA1withRSASignaturePerf took 4.055 sec
>
> --- Scott Cantor <ca...@osu.edu> wrote:
> > > Was reviewing the code....Question - If we write a class that
> > > extends SignatureAlgorithm (see SignatureBaseRSA$SignatureRSASHA1 for
> > > example, we should be able to use the NativeJCE jar without
> > > having to sign it first). Right?
> >
> > Yes, signature providers can be unsigned, it's encryption providers that
> > can't be. So you have to implement the signature algorithm without calling
> > back into the JCE.
> >
> > -- Scott
> >
>
>
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: Using XML security slows down the Axis Call
Posted by Davanum Srinivas <di...@yahoo.com>.
I just downloaded OpenSSL, compiled nativejce.dll (MSDEV on WIN32) and am able to run the tests (I
had to comment out System.loadLibrary("crypto") calls in 2 java files and keep just the
System.loadLibrary("nativejce") calls). Here's the output from the test
(http://marsalis.internet2.edu/cgi-bin/viewcvs.cgi/NativeJCE/java/tests/edu/internet2/middleware/nativejce/CryptoTests.java)
Thanks,
dims
C:\sf\NativeJCE>cat TEST-edu.internet2.middleware.nativejce.CryptoTests.txt
Testsuite: edu.internet2.middleware.nativejce.CryptoTests
Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 9.844 sec
------------- Standard Output ---------------
Native Start: 1078126144057
Native Stop: 1078126144057
Sun Start: 1078126144057
Sun Stop: 1078126144057
Native Start: 1078126144078
Native Stop: 1078126144078
Sun Start: 1078126144078
Sun Stop: 1078126144078
Native Start: 1078126144088
Native Stop: 1078126144088
Sun Start: 1078126144088
Sun Stop: 1078126144088
Native Start: 1078126144088
Native Stop: 1078126144088
Sun Start: 1078126144088
Sun Stop: 1078126144088
Sun sig Start: 1078126148644
Sun sig Stop: 1078126148704
Native sig Start: 1078126148704
Native sig Stop: 1078126148714
Sun sig Start: 1078126149635
Sun sig Stop: 1078126149666
Native sig Start: 1078126149666
Native sig Stop: 1078126149676
Sun Sig: 100 sigs in 2694 ms = 26.94 ms/run
Native Sig: 100 sigs in 851 ms = 8.51 ms/run
------------- ---------------- ---------------
Testcase: testMD5 took 0.17 sec
Testcase: testMD5_2 took 0 sec
Testcase: testSHA_1 took 0.01 sec
Testcase: testSHA_1_2 took 0 sec
Testcase: testRSA_1 took 3.204 sec
Testcase: testRSA_2 took 0.941 sec
Testcase: testSHA1withRSASignature took 0.501 sec
Testcase: testSHA1withRSASignature_2 took 0.952 sec
Testcase: testSHA1withRSASignaturePerf took 4.055 sec
--- Scott Cantor <ca...@osu.edu> wrote:
> > Was reviewing the code....Question - If we write a class that
> > extends SignatureAlgorithm (see SignatureBaseRSA$SignatureRSASHA1 for
> > example, we should be able to use the NativeJCE jar without
> > having to sign it first). Right?
>
> Yes, signature providers can be unsigned, it's encryption providers that
> can't be. So you have to implement the signature algorithm without calling
> back into the JCE.
>
> -- Scott
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: Using XML security slows down the Axis Call
Posted by Scott Cantor <ca...@osu.edu>.
> Was reviewing the code....Question - If we write a class that
> extends SignatureAlgorithm (see SignatureBaseRSA$SignatureRSASHA1 for
> example, we should be able to use the NativeJCE jar without
> having to sign it first). Right?
Yes, signature providers can be unsigned, it's encryption providers that
can't be. So you have to implement the signature algorithm without calling
back into the JCE.
-- Scott
RE: Using XML security slows down the Axis Call
Posted by Davanum Srinivas <di...@yahoo.com>.
Scott, Berin,
Was reviewing the code....Question - If we write a class that extends SignatureAlgorithm (see
SignatureBaseRSA$SignatureRSASHA1 for example, we should be able to use the NativeJCE jar without
having to sign it first). Right?
Has anyone looked in the Claymore stuff? (http://www.rtfm.com/puretls/gonative.html). It seems a
bit dated (and EOL'ed.)
-- dims
--- Scott Cantor <ca...@osu.edu> wrote:
> > Can you please post your config.xml?
>
> I don't actually have it configured in or tested yet, I was busy playing
> with Phaos' JCE while they were building this thing. I'll ask them to give
> me a copy.
>
> I can tell you more or less what's involved. You just go down into the
> section under providers and add a reference to the provider class
> (edu.internet2.middleware.nativejce.Provider) and assign it a shorthand
> name. Then you stick in a reference to the provider at the top of the
> various algorithm lists below.
>
> Looks like they've implemented MD5, SHA1, SHA1withRSA and RSA (which I think
> doesn't work because the jar isn't signed).
>
> -- Scott
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: Using XML security slows down the Axis Call
Posted by Scott Cantor <ca...@osu.edu>.
> Can you please post your config.xml?
I don't actually have it configured in or tested yet, I was busy playing
with Phaos' JCE while they were building this thing. I'll ask them to give
me a copy.
I can tell you more or less what's involved. You just go down into the
section under providers and add a reference to the provider class
(edu.internet2.middleware.nativejce.Provider) and assign it a shorthand
name. Then you stick in a reference to the provider at the top of the
various algorithm lists below.
Looks like they've implemented MD5, SHA1, SHA1withRSA and RSA (which I think
doesn't work because the jar isn't signed).
-- Scott
RE: Using XML security slows down the Axis Call
Posted by Davanum Srinivas <di...@yahoo.com>.
Can you please post your config.xml?
thanks,
dims
--- Scott Cantor <ca...@osu.edu> wrote:
> > You mentioned in your previous e-mail that you have seen significant
> > performance improvements. Is this when interfaced with xml-security?
>
> Yes, exactly. We edit the config.xml to reference the OpenSSL shim provider
> for RSAwithSHA1, some hashing, etc. That static approach to the JCE
> selection process is a bit, umm, weird.
>
> > It would be interesting to turn this (or something like it) into a fully
> > fledged library. I wonder if one could apply for a signing cert from
> > Sun to sign the provider?
>
> We looked at it, I don't think we came to any conclusions. If somebody does
> the legwork...
>
> The nice thing is it's easy to just keep adding stuff, whatever you don't
> implement will fall through to Java providers anyway.
>
> -- Scott
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: Using XML security slows down the Axis Call
Posted by Scott Cantor <ca...@osu.edu>.
> You mentioned in your previous e-mail that you have seen significant
> performance improvements. Is this when interfaced with xml-security?
Yes, exactly. We edit the config.xml to reference the OpenSSL shim provider
for RSAwithSHA1, some hashing, etc. That static approach to the JCE
selection process is a bit, umm, weird.
> It would be interesting to turn this (or something like it) into a fully
> fledged library. I wonder if one could apply for a signing cert from
> Sun to sign the provider?
We looked at it, I don't think we came to any conclusions. If somebody does
the legwork...
The nice thing is it's easy to just keep adding stuff, whatever you don't
implement will fall through to Java providers anyway.
-- Scott
Re: Using XML security slows down the Axis Call
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Scott,
That is really cool!
You mentioned in your previous e-mail that you have seen significant
performance improvements. Is this when interfaced with xml-security?
It would be interesting to turn this (or something like it) into a fully
fledged library. I wonder if one could apply for a signing cert from
Sun to sign the provider?
Cheers,
Berin
Scott Cantor wrote:
>>Is this an open-source effort? (JCE Interface to OpenSSL)?
>>i'd like to use it as well.
>
>
> Yeah, but it's not in the form of a complete solution so user beware. Just a
> few needed algorithms and operations are implemented, and we don't implement
> RSA crypto directly because it's not a signed JCE. You can plug in a
> signature provider without getting your jar signed, so Walter and Noah
> basically implemented the signature operation by calling into OpenSSL for
> the RSA crypto, but you can't invoke the RSA from Java directly outside of
> the signature calls.
>
> The code's checked into our cvs:
> http://cvs.internet2.edu/cgi-bin/viewcvs.cgi/NativeJCE/
>
> Check out details can be found on the www.opensaml.org site for that cvs.
>
> There are no copyright statements embedded in the files yet, but for now
> consider the code covered by the Shibboleth license, which is Apache-like:
> http://shibboleth.internet2.edu/license.html
>
> -- Scott
>
>
>
RE: Using XML security slows down the Axis Call
Posted by Scott Cantor <ca...@osu.edu>.
> Is this an open-source effort? (JCE Interface to OpenSSL)?
> i'd like to use it as well.
Yeah, but it's not in the form of a complete solution so user beware. Just a
few needed algorithms and operations are implemented, and we don't implement
RSA crypto directly because it's not a signed JCE. You can plug in a
signature provider without getting your jar signed, so Walter and Noah
basically implemented the signature operation by calling into OpenSSL for
the RSA crypto, but you can't invoke the RSA from Java directly outside of
the signature calls.
The code's checked into our cvs:
http://cvs.internet2.edu/cgi-bin/viewcvs.cgi/NativeJCE/
Check out details can be found on the www.opensaml.org site for that cvs.
There are no copyright statements embedded in the files yet, but for now
consider the code covered by the Shibboleth license, which is Apache-like:
http://shibboleth.internet2.edu/license.html
-- Scott
RE: Using XML security slows down the Axis Call
Posted by Davanum Srinivas <di...@yahoo.com>.
Scott,
Is this an open-source effort? (JCE Interface to OpenSSL)? i'd like to use it as well.
thanks,
dims
--- Scott Cantor <ca...@osu.edu> wrote:
> > Some time ago (6 weeks or so) I did some performance measures (WSS4J has
> > timing logs build in) and we see here that Verification/Signature
> > is real time consuming, followed by public KEy encryption, followed
> > by symmetrical encryption....this ordering comes with no surprise.
> >
> > Only the real time consumed is quite high.
>
> In our SAML authority, we've found it totally unscalable, and some of our
> contributors have been working with native code to bridge the JCE interface
> to OpenSSL. This is nice mostly because other hardware solutions based on
> PKCS11 don't get a lot of vendor support on anything but Windows and
> Solaris, and OpenSSL's engine layer does. JDK 1.5 has the PKCS11 support,
> but it doesn't do much good if you can't get the libcryptoki you need.
>
> The speeds up are dramatic, and pretty much suggest Java's unusable for this
> sort of thing, which is not a surprising conclusion to me.
>
> Note I'm talking about supporting many signatures a second. If you don't
> need that, Java's fine.
>
> -- Scott
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: Using XML security slows down the Axis Call
Posted by Scott Cantor <ca...@osu.edu>.
> Some time ago (6 weeks or so) I did some performance measures (WSS4J has
> timing logs build in) and we see here that Verification/Signature
> is real time consuming, followed by public KEy encryption, followed
> by symmetrical encryption....this ordering comes with no surprise.
>
> Only the real time consumed is quite high.
In our SAML authority, we've found it totally unscalable, and some of our
contributors have been working with native code to bridge the JCE interface
to OpenSSL. This is nice mostly because other hardware solutions based on
PKCS11 don't get a lot of vendor support on anything but Windows and
Solaris, and OpenSSL's engine layer does. JDK 1.5 has the PKCS11 support,
but it doesn't do much good if you can't get the libcryptoki you need.
The speeds up are dramatic, and pretty much suggest Java's unusable for this
sort of thing, which is not a surprising conclusion to me.
Note I'm talking about supporting many signatures a second. If you don't
need that, Java's fine.
-- Scott