Re: Sign with RsaCryptoService Provider Verify with win32 Crypto A

The signature bytes sequences would be exactly reversed, so that is
obviously not the problem.
Try to verify that the keypair you are using in .NET is exactlly the same
keypair that capi is using. .NET will automatically create
keypairs/keycontainers under certain circumstances.

It is useful sometimes in cases like this to create an "exponent of 1"
keypair, which will create the pkcs1 signature as the signature block so you
can verify internally what the actual hash value is and that the algorithm
used is identical.

- Mitch

"Leslie" <mason@xxxxxxxxxxxxxxxx> wrote in message
news:439AA5E6-D3C0-4436-AD56-80451A2E6CF0@xxxxxxxxxxxxxxxx
I had read about the reverse byte order regarding encryption but I did not
know if or how it applied to signing. I have dumped the byte arrays that
are
being signed out to the debugger and they appear to be identical. On the
capi
side, the lengths do not include the ending null.

I have listed the contents of the Crypto API signature and the
RSACryptoServiceProvider signature below. In looking at the bytes, I could
not find anything that reversing the byte order would fix. Am I missing
something?

Thanks,

Leslie

Crypto API sign - The contents of the signature buffer.
66 107 91 117 38 168 17 62 64 80 246 158 154 215 18 111 224 164 92 129 53
73
202 116 20 252 77 189 102 191 50 96 133 58 237 191 217 26 159 61 108 125
213
15 25 0 61 57 28 27 45 119 106 19 141 63 236 92 215 59 160 101 166 168 42
141
130 249 125 27 105 185 92 221 112 151 204 245 139 142 174 29 59 167 206
196
131 118 104 190 150 17 46 232 135 249 9 70 171 173 47 26 219 211 69 77 166
181 222 152 37 153 24 24 25 67 208 214 225 231 162 173 30 104 12 242 144
142

RSACryptoServiceProvider Sign - The contents of the signature buffer
151 2 221 234 243 150 106 160 185 56 31 104 186 35 135 189 128 122 149 92
209 41 86 87 218 62 98 92 193 19 109 131 247 203 172 252 81 87 145 75 25 1
174 222 54 250 6 215 13 175 100 2 184 49 104 40 115 188 63 186 114 182 48
212
0 11 57 83 127 93 192 22 132 150 52 0 228 210 26 140 132 111 110 188 195
106
171 48 250 253 68 255 145 104 6 13 25 22 240 144 199 116 134 163 109 220
30
160 201 192 83 132 134 124 117 218 116 196 130 83 58 149 54 140 56 26 173
94




"Mitch Gallant" wrote:

also CryptSignHash (and VerifySignature) generate and take a pkcs1
signature
in little-endian order. .NET creates (and expects) the reverse byte
sequence
(big-endian order).
If you are using some of the MSDN documentation for capi, and are signing
string content, are you also signing the terminal null character for the
string?
- Mitch Gallant

"lelteto" <lelteto@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4F3ACE03-BFEF-4B3E-8D11-4F37AE5E86C8@xxxxxxxxxxxxxxxx
1. Do you use the same hash algo? (eg. SHA-1)
2. What flags are you using in CryptSignHash and CryptVerifySignature
(in
your C++ code)? do you set CRYPT_NOHASHOID?
3. Is you data binary? text string? Do you specify the exact LENGTH for
both
C++ and C#?

Laszlo Elteto
SafeNet, Inc.

"Leslie" wrote:

Great. The problem I have encountered is as follows.

I setup a test program in C++ which signs some data using
CryptSignHash
and
then verifies the signature of the data using CryptVerifySignature.
All
of
this is done using the Win32 Crypto API and works just fine.

Next, I attempt to sign the same data using the
RsaCryptoServiceProvider.
The call to RSACryptoServiceProvider.SignData returns the signature
byte
array but the bytes returned do not match the signature bytes returned
from
the call to CryptSignHash in the crypto API. As a result, the call to
CryptVerifySignature using the bytes from
RSACryptoServiceProvider.SignData
fails.

Is there something I should be doing differently?

Thanks,

Leslie

Do

"Dominick Baier" wrote:

RSACryptoServiceProvider is just a thin wrapper arounf the native
Crypto
API. so yes.

-----
Dominick Baier (http://www.leastprivilege.com)

Developing More Secure Microsoft ASP.NET 2.0 Applications
(http://www.microsoft.com/mspress/books/9989.asp)

I have a web application written in C# that needs to Sign some
data
with private key that can be verified on a c++ client using win32
crypto api. Can this be done?

I would like to avoid using mixed mode on either platform if
possible.

Thanks,

Leslie









.

Relevant Pages

  • Re: Sign with RsaCryptoService Provider Verify with win32 Crypto A
    ... Exponent of one is just a keypair with unity exponent, ... Currently I am Importing the Signature Private Key using ImportCspBlob, ...
    (microsoft.public.platformsdk.security)
  • Re: Interoperability between CryptoAPI and .NET
    ... If you created an AT_SIGNATURE keypair in CryptoAPI/C++, ... type of keypair also in RSACryptoServiceProvider constructor (this is not very well documented ... If you didn't specify KeyNumber=2 above, and you don't already have an AT_SIGNATURE keypair ... container is created and populated by signature and export keys. ...
    (microsoft.public.platformsdk.security)
  • Re: Sign with RsaCryptoService Provider Verify with win32 Crypto A
    ... parameter in capi. ... even though the signature verifies just fine either way. ... Since it was on in capi and not on in RSACryptoServiceProvider ... Exponent of one is just a keypair with unity exponent, ...
    (microsoft.public.platformsdk.security)
  • Re: Sign with RsaCryptoService Provider Verify with win32 Crypto A
    ... I am not certain that this is the key that is being used for signing. ... Try to verify that the keypair you are using in .NET is exactlly the same ... which will create the pkcs1 signature as the signature block so you ... Crypto API sign - The contents of the signature buffer. ...
    (microsoft.public.platformsdk.security)
  • Re: Trouble verifying RSA signature generated with c#
    ... Reversing the signature bits fixed my problem. ... The signature blob generated oRSA.Sign is in standard big-endian order. ... BOOL GetFileBytes(LPCWSTR path, BYTE** buffer, ULONGLONG& bufferSize) ...
    (microsoft.public.platformsdk.security)