Generation of Custom RSA private key

[Hirnhamser]

Hey Guys,
I m trying to generate my own RSA private key, but I m not sure how to
calculte it for the .pem File.
I do usually use C# as a programming language and the private keys are
stored like this:

<RSAKeyValue>
<Modulus>sTKEezRMtAGSs2EFTidhPAEhX9El6RofutG+GUB9d2V/z47K/
TngXpyzi552v5jyqbJAhhQCnA92NnORhcxXevocIQUb0MEGbI12o
+5TDowVNONfOlbLfzjAWPOQGdpQI6mhkmAl0yB5MUIJXVut4oMgmLrYJ4JG9IWokeW8UMM=
</Modulus>
<Exponent>AQAB</Exponent>
<P>6o9tsvsoNXG/imjtGJ2/ZJz1qcondovNogOUJHd11KBdKY3cMQMx9Nt2ldOtidDETEjf
+qgXAx7O9dOmpcOtfw==</P>
<Q>wWTUjX25HJ9Lvq7YtYNAvIOg6Z3GqfqODxSlUJpD8QpMAdTdJzHPsrgOWlTvDk1zg/
tCfqX1R4QNPDuZWGvGvQ==</Q>
<DP>hpcYRhwRfWEwnBYK/hX+LZhW6j9CF6aurqlJBwe5B/
Ggo2hwEXuY3bxUNjKJIEw3ZuJmCukKk1LJRItW00UNtw==</DP>
<DQ>DwmwHXBxPHCGi0U9RJ/4ILB7iq7iC8WX1kRctm/
IaK3MSzgqGiodZGA7fXqtPAd5vAGFoiN1dyIlhVF9EwsOYQ==</DQ>
<InverseQ>p97FzrSG1U9OAg6IoaH7gV77CxtpGREM8n04SY5wrNTES/MlWel30CnxSJJy
+n404GrCBX83ejKMGEZb+oHc+A==</InverseQ>
<D>o/hwWaYS2HugKfe8tg6Azsro/
EaIw0TWWcUfGTTxJVw6QnILavp0onh1ONzBXBkHbHqzdJ7tr0YriMW2ws5Nn8Xv5RenAtN1o7Vl6Dx4tZjJlfm/
iLmrju5IaCRggz53xnsuYx0S/nPWbHgz94y/1CDBG3kYeIkrgwtRFFalpak=
</D>
</RSAKeyValue>

In the xmlsec example file privkey.pem, the key is stored like this:

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA7bXTMjOSElQ9VM/gRwD68VSejdXmaJ34NwzL2VU9GcuuPqnF
4/M7hwupaJQ7Hxpw/C1Lba2kO6gi/mxyqbPoYwIQkXceVnJ+Ig65RacRS+yDZ6+r
3pM7AkOOQT1K75LBfRSmu8l+IkgwbrZj36E9eID5yLknvGOVHhnui5OrBdFoB8i/
iZsTrt++yroWodqV2dfs+1eCSJTYHpibSpaq74BnrhPU2oHxh1C/QbmSuX1Mf0Ug
1I6sVHilN337fXxiAGZdHXborQtjrb+Ha9YMS61JiPmWe+RZrXykE+0pkvdkFSNg
eVgD5S9W5274ZGYssO5xRPkP8BidpshOESBY3QIDAQABAoIBAE5f7MpYhojUjYQx
JdlDUXnQVJafN+C2dOhxp6R4njSrG0A96alGwRG9npWEihmvNiFvLbdz0Pp6bU9F
omihkLVUMPJFPBN0nHHOOPfmJaXKzWiaWyh/kq0kaPrJorNqx7Dd5jt0K8pR0uYt
7LAHEaVxoOm1YoySqM/L7QLIJVM9HUj31FZEXsDO68C13c6C35cPkU1tP6PfIouA
pQuDA1TvkFCo8RqIBUIxcj/yKvjQgnbeNqDwzz5St+2m4wSUw+8EprwJivx/WEjr
k/c1AVZV2Yx1HP/zf/3IaC7c6IWnKxpvPQgwzJ6/SoHKXKcb3Y7yhe3xJTfRj8v4
u1hJHgECgYEA+bfDvxEymR3wO08eEgvFfnr/XmziKwWTYHV+pkNvgVVCOvfJgOZn
9RMzYxHAo61NNpZ5OidEGZZ9jenuy9hK8K5kTqnaRMlFJ/80nq6S04dODsOJFEzq
8YFmTI7/G502FN/FHPUGV0wmxBDI1Zt5LNlb5KFLBxeniE9CFV+y3o0CgYEA87C6
obaTQn1wQ+PZEticFIESRf2m8gYTrxNPyRh/OgAAgXFGnFL2cj0QIhIow1Gev9tU
adywFIF89b8elHMm6n+vVyO1lC31kPr77GcYqMHSk+5+tU32Fx7QOp6+k8Iy2Lb/
xlHTv/AvOpXzlt9h5vn5/bTASiMkgYPHuOsAN5ECgYAbgrc58XcVj0rL/edeLZXQ
XVSM3on8G10lH0yYnI1IPlBRlsLIRJnnUfozS91hKtJ61RD96x2BhCbI36DDLEz1
PwEl+Whmc5X+1grCAJGEZD+hOMF9TwwDFzJh9M7+B8/RdOWOTyAntef/aan2fm5X
FosdIPfXDDAUwEaTfDuEcQKBgQDm/QkbCj2x08cbgxkbBRmFUgcpMtMRLHNyC2Mg
YckPCDtydxYQTY9vH7RwJzheU7qfb14nblm1RjxVkJCC9FfaBagFeELAr4PKpi0v
m1XDeN2K/ZE7eCehKMMGHbzVwEmEJIpzyNJnaFrMNKENzLY3Q5IUS0XNwFv1LB2f
iZnOEQKBgFEu9v61M2ekBJAsJ/U/3siOCRDN2B4PEbEaQX9m8Cc6xDP5PnQTwy0D
MY85r37CK7vSp35sBaYdmMBgrwBfQiO8Oj7NaECdcM+wyvvZbC0EVYk9CykIJyxK
h40CmyxXxzwZcDhgoMqkmuvvo/iN12P+kt3J6cuWbr3Xl8ORLTYw
-----END RSA PRIVATE KEY-----

So Im wondering how I can "convert" the C# version in the "xmlsec
version".

Best Regards
Pascal

[Rob Richards]

That structure looks like its for an xml enc/sig already. Do you have
the origional key it was pulled from (maybe from the windows cert
store)? If so you can do an export of it to pkcs #12 and then use
openssl to convert it to pem.

Rob

[Hirnhamser]

I'm only getting the key itself (in the XML Format outlined above),
nothing more. I have found a project that converts from the PEM
representation to the "c#" one under http://www.jensign.com/opensslkey/
Unfortunately I need it the other way around..

[Hirnhamser]

I found a solution for that problem. Have a look at the Chillkat
Component at http://www.chilkatsoft.com/refdoc/csPrivateKeyRef.html
It provides functiones to load and save RSA Keys in arbitrary formats.

So here is what I did:
I created a RSA keypair with the .Net Framework (using the
RSACryptoServiceProvider
http://msdn.microsoft.com/en-us/library/system.security.cryptography.rsacryptoserviceprovider.aspx
). Then I converted the private key to PEM format, using the Chilkat
component. I rechecked the result with the the tool I posted above
( http://www.jensign.com/opensslkey/ ) by converting the PEM formatted
private key back to the XML representation - the key were the same.

Unfortunately, there is still a problem, because the SignatureValue
generated by the .Net Framework is different from the one produced by
xmlseclibs.
The DigestValue is the same, though. As far as I understood, the
Digest is a hash of the content - which is then encrypted by RSA. Did
I get that right?
If thats the case, the problem must be somewhere in the encryption
process.

Im a little lost right now, because I don't know where to look for the
error. Any Ideas?

Regards
Pascal

[Rob Richards]

I would check the whitespace used in the SignedInfo subtree between the
2 documents. In the majority of cases where people have reported a
problem when comparing the SignatureValue that is calculated it ended up
being the difference in use of whitespace. Whitespace is significant and
is taken into account when calculating the SignatureValue.

Rob

[Hirnhamser]

> >> representation to the "c#" one underhttp://www.jensign.com/opensslkey/

> >> Unfortunately I need it the other way around..
> > I found a solution for that problem. Have a look at the Chillkat

> > Component athttp://www.chilkatsoft.com/refdoc/csPrivateKeyRef.html

> > It provides functiones to load and save RSA Keys in arbitrary formats.
>
> > So here is what I did:
> > I created a RSA keypair with the .Net Framework (using the
> > RSACryptoServiceProvider

> >http://msdn.microsoft.com/en-us/library/system.security.cryptography....

> > ). Then I converted the private key to PEM format, using the Chilkat
> > component. I rechecked the result with the the tool I posted above

> > (http://www.jensign.com/opensslkey/) by converting the PEM formatted

> > private key back to the XML representation - the key were the same.
>
> > Unfortunately, there is still a problem, because the SignatureValue
> > generated by the .Net Framework is different from the one produced by
> > xmlseclibs.
> > The DigestValue is the same, though. As far as I understood, the
> > Digest is a hash of the content - which is then encrypted by RSA. Did
> > I get that right?
> > If thats the case, the problem must be somewhere in the encryption
> > process.
>
> > Im a little lost right now, because I don't know where to look for the
> > error. Any Ideas?
>
> I would check the whitespace used in the SignedInfo subtree between the
> 2 documents. In the majority of cases where people have reported a
> problem when comparing the SignatureValue that is calculated it ended up
> being the difference in use of whitespace. Whitespace is significant and
> is taken into account when calculating the SignatureValue.
>
> Rob

Which information is actually used to calculate the Signature? As I
said, so far i was thinking that the Signature does only calculate the
RSA encrypted Value of the Digest. I have noticed that C# does not use
namespaces to specify the Signature XML elements while xmlseclib does.
There is also a small difference in the whitespaces. I uploaded 3
files to show the differences

1. Signature generated by C#
http://www.b-landau.de/upload/c_sharp.xml

2. Signature generated by xmlseclib
http://www.b-landau.de/upload/xmlseclibs.xml

3. input xml
http://www.b-landau.de/upload/input.xml

The generation was done by openening the input.xml, get the contents
and encrypt it, so that copy and paste mistakes can be excluded.
As I mentioned, there is a differnce in the namespace and in the
whitespaces. Could that be the cause? if yes, how can i change this,
because the KeyInfo is auto generated..?

Pascal

[Rob Richards]

The signature is calculated using the canonicalized SignedInfo element
so the whitespace and namespaces are definitely the reason why the
signature values are different. Both are correct and the signed
documents are interoperable. You should be able to verify the signed
document in C# that was produced by xmlseclibs and vice-versa. If you
truly need for some reason to generate the exact same structure you
would need to modify the code within xmlseclibs to use a default
namespace rather than using a prefix as well as remove the formatting it
uses in the SignedInfo structure, but again there really is no need to
do that as both documents (C# and xmlseclibs) are valid and properly signed.

Rob

[Hirnhamser]

Thank you for the heads up regarding the SignedInfo. Its nice to know
what is REALLY encryped in the Signature.
You are right, both documents are encryped correctly. I checked them
with the test file xmlsec-verify.phpt in the
xmlseclib project. I got a "Signature validated!" for both files.

So the problem has to be somewhere in the .Net Framework.

Anyway, I would like to test the encryption/decryption when the same
Signature is produced. Therefore I tried
to remove the Namespaces from the xmlseclib solution, but the
encryption didnt work after my modifications.

Would you mind to post a "modified" xmlseclibs.php, that does neither
produce any formatted output (whitespacesproblem)
nor uses namespaces? I debugged through the code myself, but I have
very little knowledge when it comes to encryption (or even XML)
in PHP...

Regards
Pascal

[Rob Richards]

Have you tried just changing the template const in the XMLSecurityDSig
class to something like:

const template = '<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo><SignatureMethod /></SignedInfo></Signature>';

I havent gone through all the code, but dont think I am relying on a
hard coded ds prefix anywhere to perform any actions. I no longer have
my changes but I also had done the same thing at least over a year ago
in order to compare some .NET produced document as well and know that
the change was fairly simple to accomplish this.

Rob

[Hirnhamser]

Hey,
I finally got it to work. I have to admit that it was a stupid mistake
of mine...
In my C# verification method I did not set
"preserveWhitespaces" (property of XmlDocument) to true which cause
the validation to fail constantly.
In the end it has nothing to do with namespaces or whitespaces.

Anyway, thx for your patient help Rob - I have learned at lot more
about XML Signature than I intended to :)