Problems in encrypting with AES_192 and AES_256
Hi All,
I'm trying to simply encrypt a simple XML file with the encryption
sample available.
org.apache.xml.security.samples.encryption.Encrypter;
But I get the foollowning exception when I set the key size to 192 or
256 in the GenerateDataEncryptionKey() method.
java.lang.SecurityException: Unsupported keysize or algorithm parameters
at javax.crypto.Cipher.init(DashoA6275)
at org.apache.xml.security.encryption.XMLCipher.encryptData(XMLCipher.java:957)
at
org.apache.xml.security.encryption.XMLCipher.encryptElementContent(XMLCipher.java:735)
at org.apache.xml.security.encryption.XMLCipher.doFinal(XMLCipher.java:858)
at
org.apache.xml.security.samples.encryption.Encrypter.main(Encrypter.java:195)
Can someone please explain whether I'm doing some thing theoritically
wrong or the correct way to encrypt using AES 192 and AES 256.
Thanks,
Ruchith
private static SecretKey GenerateDataEncryptionKey() throws Exception {
String jceAlgorithmName = "AES";
KeyGenerator keyGenerator =
KeyGenerator.getInstance(jceAlgorithmName);
keyGenerator.init(192); //Setting the key length :-?
return keyGenerator.generateKey();
}
Re: New Bee help required
Hi, For info about WSS4J you can try some of the link listed here [1]. Also wss4j-dev@ws.apache.org list is available for specific questions on WSS4J. Thanks, Ruchith [1] http://marc.theaimsgroup.com/?l=wss4j-dev&m=113877713719345&w=2 On 3/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Hi All, > > I am trying to use Apache WSS4j and XML signing for my project. I am a > new bee in this area. I appreciate if anyone can help me or guide me with > some links which I can follow and get started > > Thanks, > G. Dhanoa
Cannot sign-verify twice in the same thread with different XMLSignature instances
Hi Devs, I ran into an "java.security.SignatureException: object not initialized for verification" exception when trying to do sign and verify *twice* in the same thread, using different XMLSignature instances. I tracked this down to the use of "keysVerify" thread local tracker in org.apache.xml.security.algorithms.SignatureAlgorithm to tack the initialization of the java.security.Signature instance with private/public keys. When the first signature verification occurs the public key is set in "keysVerify" in SignatureAlgorithm#initVerify(). And it verifies successfully. But when we try to carryout the second verification the "keysVerify" returns the same key for the thread and the java.security.Signature instance is not initialized with the public key. Therefore we run into the above exception. What do you folks think? Have I overlooked something in my scenario? Thanks, Ruchith -- www.ruchith.org
Re: Cannot sign-verify twice in the same thread with different XMLSignature instances
Hi Raul, I'm using the SVN head (revision : 470741). I'm working on fixing the issue dims reported yesterday[1] and fixing WSS4J/Rampart and AXIOM to work with the changes :-). And I have a patch for [1] which I will post soon. I will try to send a test case as soon as I possible, Until then you can easily reproduce the error with WSS4J test suite. You can get a chackout of [2] and simply run "ant clean test" to run the unit tests after replacing the xml-sec-1.3.0.jar in the lib dir with the latest. Thanks, Ruchith [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=40880 [2] https://svn.apache.org/repos/asf/webservices/wss4j/trunk On 11/3/06, Raul Benito <[EMAIL PROTECTED]> wrote: Hi Ruchith, It looks strange to me, because all the junits that we pass do in essence what are you describing(several verifying in one thread). But on the other hand your explanation looks sound. What version of xmlsec are you using? Can you post a simple test case that triggers this error? Regards, Raul On 11/3/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > Hi Devs, > > I ran into an "java.security.SignatureException: object not > initialized for verification" exception when trying to do sign and > verify *twice* in the same thread, using different XMLSignature > instances. > > I tracked this down to the use of "keysVerify" thread local tracker in > org.apache.xml.security.algorithms.SignatureAlgorithm to tack the > initialization of the java.security.Signature instance with > private/public keys. > > When the first signature verification occurs the public key is set in > "keysVerify" in SignatureAlgorithm#initVerify(). And it verifies > successfully. But when we try to carryout the second verification the > "keysVerify" returns the same key for the thread and the > java.security.Signature instance is not initialized with the public > key. Therefore we run into the above exception. > > What do you folks think? Have I overlooked something in my scenario? > > Thanks, > Ruchith > > -- > www.ruchith.org > -- http://r-bg.com -- www.ruchith.org
Re: Cannot sign-verify twice in the same thread with different XMLSignature instances
Hi Raul, I was able to reproduce the issue. Please drop the attached interop.jks file to your classpath along with xml-sec and other pre-reqs and run the test case (TestSig.java). I ran this inside my IDE within the xml-security project. The exception stack trace is here : http://rafb.net/paste/results/QSCZ1587.html Thanks, Ruchith On 11/3/06, Raul Benito <[EMAIL PROTECTED]> wrote: Can you also post the exception backtrace? Regards, On 11/3/06, Raul Benito <[EMAIL PROTECTED]> wrote: > Hi Ruchith, > It is not feasible for me to checkout the whole wss4j in order to see > the problem. > Did the problem arise when you do something like this? > PrivateKey xk; PublicKey pk=xk.getPublickKey(); > XMLSignature s1=...; > XMLSignature s2=...; > s1.sign(xk); > s2.sign(xk); > s1.checkSignatureValue(pk); > > Or other kind of sequence? > Regards, > > > > On 11/3/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > > Hi Raul, > > > > I'm using the SVN head (revision : 470741). > > > > I'm working on fixing the issue dims reported yesterday[1] and fixing > > WSS4J/Rampart and AXIOM to work with the changes :-). And I have a > > patch for [1] which I will post soon. > > > > I will try to send a test case as soon as I possible, > > > > Until then you can easily reproduce the error with WSS4J test suite. > > You can get a chackout of [2] and simply run "ant clean test" to run > > the unit tests after replacing the xml-sec-1.3.0.jar in the lib dir > > with the latest. > > > > Thanks, > > Ruchith > > > > [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=40880 > > [2] https://svn.apache.org/repos/asf/webservices/wss4j/trunk > > > > On 11/3/06, Raul Benito <[EMAIL PROTECTED]> wrote: > > > Hi Ruchith, > > > > > > It looks strange to me, because all the junits that we pass do in > > > essence what are you describing(several verifying in one thread). But > > > on the other hand your explanation looks sound. > > > What version of xmlsec are you using? > > > Can you post a simple test case that triggers this error? > > > > > > Regards, > > > > > > Raul > > > > > > On 11/3/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > > > > Hi Devs, > > > > > > > > I ran into an "java.security.SignatureException: object not > > > > initialized for verification" exception when trying to do sign and > > > > verify *twice* in the same thread, using different XMLSignature > > > > instances. > > > > > > > > I tracked this down to the use of "keysVerify" thread local tracker in > > > > org.apache.xml.security.algorithms.SignatureAlgorithm to tack the > > > > initialization of the java.security.Signature instance with > > > > private/public keys. > > > > > > > > When the first signature verification occurs the public key is set in > > > > "keysVerify" in SignatureAlgorithm#initVerify(). And it verifies > > > > successfully. But when we try to carryout the second verification the > > > > "keysVerify" returns the same key for the thread and the > > > > java.security.Signature instance is not initialized with the public > > > > key. Therefore we run into the above exception. > > > > > > > > What do you folks think? Have I overlooked something in my scenario? > > > > > > > > Thanks, > > > > Ruchith > > > > > > > > -- > > > > www.ruchith.org > > > > > > > > > > > > > -- > > > http://r-bg.com > > > > > > > > > -- > > www.ruchith.org > > > > > -- > http://r-bg.com > -- http://r-bg.com -- www.ruchith.org interop.jks Description: Binary data import org.apache.xml.security.algorithms.SignatureAlgorithm; import org.apache.xml.security.c14n.Canonicalizer; import org.apache.xml.security.keys.KeyInfo; import org.apache.xml.security.samples.utils.resolver.OfflineResolver; import org.apache.xml.security.signature.XMLSignature; import org.apache.xml.security.transforms.Transforms; import org.apache.xml.security.utils.Constants; import org.apache.xml.security.utils.XMLUtils; import org.apache.xpath.XPathAPI; import org.w3c.dom.Element; import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream; import java.security.KeyStore; import java.security.PrivateKey; import java.security.PublicKey; import java.security.cert.X509Certificat
Re: Cannot sign-verify twice in the same thread with different XMLSignature instances
Hi Raul, On 11/5/06, Raul Benito <[EMAIL PROTECTED]> wrote: You Wss4j guy always using untested XMLSignature constructors!!! ;) Just joking. You hit again another XMLSignature constructor that there is no unit test for it. The problem is that for creating new Signatures(for signing) public XMLSignature( Document doc, String BaseURI, Element SignatureMethodElem, Element CanonicalizationMethodElem) throws XMLSecurityException Use the SignatureAlgorithm (Element) constructor, that normally is only used for verifying. I just reviewed the WSS4J signature code ...the reason for using this constructor is to provide the "CanonicalizationMethod" element carrying an "InclusiveNamespaces" element, to be included in "SignedInfo". See here [1] for the code snippet from WSS4J where we create the XMLSignature instance. The SignatureAlgorith obtain a java.security.Signature from the verifying pool but is going to be use for signing and when latter is recycled for verifying it gives you the error. Now the SignatureAlgorihtm is more lazy and only obtains a signature when asked for sign or verify and obtain it from the right pool. Anyway you are doing a lot of redundat work creating firs a SignatureAlgorithm DOMificated it and later make the XMLSignature library read it again from DOM. (Before the fix it will be worse as it obtain a new java.security.Signature that is even slower). Perhaps I should take a look in WSS4J for performance improvements. A big +1 ! Can you raise a bug report in bugzilla, for proper tracking? will do. Thanks, Ruchith [1] http://rafb.net/paste/results/TYGEY793.html Regards, And thanks for finding the bug. On 11/4/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > Hi Raul, > > I was able to reproduce the issue. > > Please drop the attached interop.jks file to your classpath along with > xml-sec and other pre-reqs and run the test case (TestSig.java). I ran > this inside my IDE within the xml-security project. > > The exception stack trace is here : > http://rafb.net/paste/results/QSCZ1587.html > > Thanks, > Ruchith > > On 11/3/06, Raul Benito <[EMAIL PROTECTED]> wrote: > > Can you also post the exception backtrace? > > Regards, > > > > On 11/3/06, Raul Benito <[EMAIL PROTECTED]> wrote: > > > Hi Ruchith, > > > It is not feasible for me to checkout the whole wss4j in order to see > > > the problem. > > > Did the problem arise when you do something like this? > > > PrivateKey xk; PublicKey pk=xk.getPublickKey(); > > > XMLSignature s1=...; > > > XMLSignature s2=...; > > > s1.sign(xk); > > > s2.sign(xk); > > > s1.checkSignatureValue(pk); > > > > > > Or other kind of sequence? > > > Regards, > > > > > > > > > > > > On 11/3/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > > > > Hi Raul, > > > > > > > > I'm using the SVN head (revision : 470741). > > > > > > > > I'm working on fixing the issue dims reported yesterday[1] and fixing > > > > WSS4J/Rampart and AXIOM to work with the changes :-). And I have a > > > > patch for [1] which I will post soon. > > > > > > > > I will try to send a test case as soon as I possible, > > > > > > > > Until then you can easily reproduce the error with WSS4J test suite. > > > > You can get a chackout of [2] and simply run "ant clean test" to run > > > > the unit tests after replacing the xml-sec-1.3.0.jar in the lib dir > > > > with the latest. > > > > > > > > Thanks, > > > > Ruchith > > > > > > > > [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=40880 > > > > [2] https://svn.apache.org/repos/asf/webservices/wss4j/trunk > > > > > > > > On 11/3/06, Raul Benito <[EMAIL PROTECTED]> wrote: > > > > > Hi Ruchith, > > > > > > > > > > It looks strange to me, because all the junits that we pass do in > > > > > essence what are you describing(several verifying in one thread). But > > > > > on the other hand your explanation looks sound. > > > > > What version of xmlsec are you using? > > > > > Can you post a simple test case that triggers this error? > > > > > > > > > > Regards, > > > > > > > > > > Raul > > > > > > > > > > On 11/3/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > > > > > > Hi Devs, > > > > > > > > > > >
Re: Cannot sign-verify twice in the same thread with different XMLSignature instances
> Can you raise a bug report in bugzilla, for proper tracking? will do. Done : http://issues.apache.org/bugzilla/show_bug.cgi?id=40896 Thanks, Ruchith -- www.ruchith.org
Re: Cannot sign-verify twice in the same thread with different XMLSignature instances
Hi Raul, thanks a lot for the quick fix ! Thanks, Ruchith On 11/5/06, Raul Benito <[EMAIL PROTECTED]> wrote: On 11/5/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > Hi Raul, > > On 11/5/06, Raul Benito <[EMAIL PROTECTED]> wrote: > > You Wss4j guy always using untested XMLSignature constructors!!! ;) > > Just joking. You hit again another XMLSignature constructor that there > > is no unit test for it. > > The problem is that for creating new Signatures(for signing) > > public XMLSignature( Document doc, String BaseURI, > > Element SignatureMethodElem, Element CanonicalizationMethodElem) > > throws XMLSecurityException > > > > Use the SignatureAlgorithm (Element) constructor, that normally is > > only used for verifying. > > I just reviewed the WSS4J signature code ...the reason for using this > constructor is to provide the "CanonicalizationMethod" element > carrying an "InclusiveNamespaces" element, to be included in > "SignedInfo". > > See here [1] for the code snippet from WSS4J where we create the > XMLSignature instance. > I will take a look, I promise. But this week will be impossible. Anyway the fix in the svn head -- www.ruchith.org
Re: VOTE: Apache XML Security Java Library 1.4 Release
Hi Raul, I just discovered some more signature faliures in WSS4J with the latest XML-Sec SVN HEAD :-(. at the first glance it seems like an issue with C14N ... please give me a few more hours I will try to pin point the issue ... maybe an issue with WSS4J itself . Thanks, Ruchith On 11/13/06, Raul Benito <[EMAIL PROTECTED]> wrote: Do you think that the SVN head of java is in shape for doing the 1.4 release? [ ] +1 , We have delayed it too much [ ] 0 , We should do, but I'm not very confident. [ ] -1, It fails (...) -- http://r-bg.com -- www.ruchith.org
Re: VOTE: Apache XML Security Java Library 1.4 Release
false alarm ... million apologies ! ... its early morning over here in Sri Lanka :-) Was using the wrong constructor ! All WSS4J unit tests passes with the latest xml-sec svn HEAD. Thanks, Ruchith On 11/16/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: Hi Raul, I just discovered some more signature faliures in WSS4J with the latest XML-Sec SVN HEAD :-(. at the first glance it seems like an issue with C14N ... please give me a few more hours I will try to pin point the issue ... maybe an issue with WSS4J itself . Thanks, Ruchith On 11/13/06, Raul Benito <[EMAIL PROTECTED]> wrote: > Do you think that the SVN head of java is in shape for doing the 1.4 release? > [ ] +1 , We have delayed it too much > [ ] 0 , We should do, but I'm not very confident. > [ ] -1, It fails (...) > > > -- > http://r-bg.com > -- www.ruchith.org -- www.ruchith.org
Signature verification fails due to Java object reference mismatch in ElementProxy#guaranteeThatElementInCorrectSpace()
Hi Devs,
ElementProxy#guaranteeThatElementInCorrectSpace() method contains the
following check :
if ((namespaceSHOULDBE!=namespaceIS) ||
!localnameSHOULDBE.equals(localnameIS) ) {
Object exArgs[] = { namespaceIS +":"+ localnameIS,
namespaceSHOULDBE +":"+ localnameSHOULDBE};
throw new XMLSecurityException("xml.WrongElement", exArgs);
}
I'm using opensaml-1.1b and I encounter a signature failure due to
namespaceIS object not being the same object as namespaceSHOULDBE. Is
this intentional (Apologies if I overlooked something obvious)? Or can
we change this to the following:
if (!namespaceSHOULDBE.equals(namespaceIS)) ||
!localnameSHOULDBE.equals(localnameIS) ) {
Object exArgs[] = { namespaceIS +":"+ localnameIS,
namespaceSHOULDBE +":"+ localnameSHOULDBE};
throw new XMLSecurityException("xml.WrongElement", exArgs);
}
Thanks,
Ruchith
Re: Signature verification fails due to Java object reference mismatch in ElementProxy#guaranteeThatElementInCorrectSpace()
HI Raul,
I'm using AXIOM DOOM [1] a StAX based DOM implementation. I'll check Axiom code.
Thanks,
Ruchith
[1] http://ws.apache.org/commons/axiom/
On 7/16/07, Raul Benito <[EMAIL PROTECTED]> wrote:
Hi Ruchith,
What XML parser are you using?
All common XML parsers intern the namespaces. Anyway I'm working in
plug-able corrects in order to change this behavior even disable it.
Regards,
On 7/15/07, Ruchith Fernando <[EMAIL PROTECTED]> wrote:
> Hi Devs,
>
> ElementProxy#guaranteeThatElementInCorrectSpace() method
contains the
> following check :
>
> if ((namespaceSHOULDBE!=namespaceIS) ||
>!localnameSHOULDBE.equals(localnameIS) ) {
> Object exArgs[] = { namespaceIS +":"+ localnameIS,
>namespaceSHOULDBE +":"+ localnameSHOULDBE};
> throw new XMLSecurityException("xml.WrongElement", exArgs);
> }
>
> I'm using opensaml-1.1b and I encounter a signature failure due to
> namespaceIS object not being the same object as namespaceSHOULDBE. Is
> this intentional (Apologies if I overlooked something obvious)? Or can
> we change this to the following:
>
> if (!namespaceSHOULDBE.equals(namespaceIS)) ||
>!localnameSHOULDBE.equals(localnameIS) ) {
> Object exArgs[] = { namespaceIS +":"+ localnameIS,
>namespaceSHOULDBE +":"+ localnameSHOULDBE};
> throw new XMLSecurityException(" xml.WrongElement", exArgs);
> }
>
> Thanks,
> Ruchith
>
--
http://r-bg.com
--
www.ruchith.org
www.wso2.org
xmlsec-1.4.1.jar in m2 repo
Hi Devs, Can we please add xmlsec-1.4.1.jar to this [1] location. I think the xmlsec-1.4.1.jar will have to be signed and the signature file (xmlsec-1.4.1.jar.asc) and md5 digest file (xmlsec-1.4.1.jar.md5) will have to be included in the same dir. The Apache Rampart project is waiting for this [2] to upgrade to xmlsec-1.4.1 due to the use of Maven2 build system. Thanks, Ruchith p.s. I have access to this dir and can add it but I think the release manager will have to sign the jar. [1] http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/santuario/xmlsec/1.4.1/ [2] https://issues.apache.org/jira/browse/RAMPART-101 -- http://blog.ruchith.org http://wso2.org
Re: Controlling placement of in result XML tree
Hi,
If you are planning to sign the message the standard [1] way then you
will have to place the "Signature" element in the "Security" header of
the SOAP message. The WS-Sec spcefication describes how to encrypt
and/or sign the message while preserving SOAP envelop structure.
You can do this using the Apache WSS4J if you are planning to
sign/encrypt SOAP messages.
Thanks,
Ruchith
1.
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
On Nov 9, 2007 8:03 PM, <[EMAIL PROTECTED]> wrote:
> Hi,
>
> How do I determine where the element is placed in the result
> XML? E.g., I have a SOAP message like this:
>
>
>
>
> ...
>
>
>
> My code signs only the part (using XPath-Transforms). In the
> resulting tree, the signature is added *after* the :
>
>
> ...
>
> ...
>
>
> I would, however, like to add it to the part:
>
>
> ...
> ...
>
>
>
> Reason: that way, I can just encrypt the (replace with
> ) and preserve a correct SOAP message (with a Body
> element). The way it is now, I would encrypt the and have a
> signature "on the outside", which I consider weaker due to the weaknesses in
> SHA1.
>
> The code for the XPath-Transformation is
>
> String filter[][] = { { XPath2FilterContainer.INTERSECT,
> "//Envelope/Body/message" } };
> transforms.addTransform(Transforms.TRANSFORM_XPATH2FILTER,
> XPath2FilterContainer.newInstances(insideDoc, filter));
>
> Which I think is correct. Where do I make the mistake?
>
> Thanks,
> Ralph
>
> --
> For contact details, please see www.ralphholz.de.
>
--
http://blog.ruchith.org
http://wso2.org
Re: Java XMLSec 1.4.2 Release
Hi Sean, Can we please have the xmlsec-1.4.2.jar in the maven repo. (It should go into a 1.4.2 directory here [1]) ? This will really help projects like Apache WSS4J and Apache Rampart that use maven2 build system. Thanks, Ruchith 1. http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/santuario/xmlsec/ On Tue, Jun 24, 2008 at 2:50 AM, Sean Mullan <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm happy to announce that the final release of Java XMLSec 1.4.2 is now > available. See the web site http://santuario.apache.org for more details on > the release or download it from > http://xml.apache.org/security/dist/java-library/ > > The main highlights of this release are: > > 1) 22 bugs and rfes have been fixed > 2) A new implementation of C14N 1.1 > 3) A potentially serious XML Encryption bug in 1.4.1 was addressed, so > please upgrade to 1.4.2 if you use XML Encryption. See > https://issues.apache.org/bugzilla/show_bug.cgi?id=42886 > > Thanks for all the contributions and please keep reporting any bugs that you > find. > > --Sean > -- http://blog.ruchith.org http://wso2.org
