OpenSAML user discussion

[Brent Putman <>]

Dimuthu Leelarathne wrote:
> It was a issue in creating the modulus and exponent as a BigInteger. The
> problem is either inside the org.opensaml.xml.util.Base64 or the way
> create the BigInteger.
>
>   



Ok.  Yes, I think we have a bug in java-xmltooling with respect to how 
we handle the conversion between Java BigInteger types and the 
ds:CryptoBinary type defined in the XML Signature spec.  I'll have to 
confirm and make sure I understand the problem fully before I fix, but I 
think that's it.  The Java BigInteger byte representation assumes the 
presence of the leading sign bit within the byte[] on the single arg 
constructor, and similarly includes it on the toByteArray() method.

In your SAML2Test.java, if you instead use the 2-arg constructor like 
this, you should see that it works correctly.  In this case you are 
specifying the sign and magnitude of the big int separately. 

       BigInteger mod = new BigInteger(1, Base64.decode(modulus));
       BigInteger exp = new BigInteger(1, Base64.decode(exponent));


Because we are (apparently) consistently doing the wrong thing on both 
encoding and decoding, things erroneously seem to work correctly 
internally when roundtrip encoding and then decoding within Java OpenSAML.

This bug has been there since Dec 2006, so I guess that shows how many 
people have tried to use  ds:RSAKeyValue and ds:DSAKeyValue (the things 
which use the ds:CryptoBinary schema type) in a library inter-op 
scenario.  :-)

Thanks,
Brent