Thanks for all the great suggestions guys.
I'll double-check the key -- I just assumed it would be correct
because my colleague is able to verify the message in Java with the
same key. My colleague got the key directly from the Java PublicKey
interface -- maybe he can give me the hex encoding of the public key.
My colleague did mention on Friday that in Java he is converting the
string message to a UTF-16 encoded byte array (he does the same thing
before he signs the message). In my code I am not doing any
conversion of the string. Maybe I need to convert the message to a
wide character array? This should definitely be causing the
verification to fail -- but I wonder if this is the only problem.
I don't go back to work until Tuesday so I'll try then and post back
here what I find.
On Mar 14, 11:39 pm, "Jeffrey Walton" <[EMAIL PROTECTED]> wrote:
> Hi Unfleshed One,
>
> > Signed char -126 is 130 when converted to unsigned char (256 - x).
> > So assuming original byte was 0x82 that's perfectly fine.
>
> Introp can be frustrating for at times. Crypto++ is usually our first
> language. We see tricks like this, and we are suspect. It's something
> else we have to question because we are not as familiar with languages
> such as Java, Bouncy Castle, mcrypt, C#, etc.
>
> Can you pick another language/libray such as C# (another area I am
> familiar) or OpenSSL (another area Geoff is familiar)? Just
> kidding....
>
> > > Ronald, I never used DSA, so I can't tell if you use it correctly,
>
> DSA uses a random parameter (k). So you will probably have a difficult
> time producing the exact output in each library. Below, your signature
> on m is the pair (r,s)
>
> 1) select random k
> 2) compute r = (a^k mod p) mod q
> 3) compute k^-1 mod q
> 4) compute s = k^-1{ h(m) +ar } mod q
>
> I recall seeing some source code posted for Java/Crpyto++ Interop on
> the mailing list by Donald Bergstrom. It is a 3DES sample, but het
> works out all the wrinkles (String versus Byte[], etc).
> Seehttp://groups.google.com/group/cryptopp-users/browse_thread/thread/91...
>
> Here's other topics of ineterst:
> 1) Test the Java encoders -
> seehttp://groups.google.com/group/cryptopp-users/browse_thread/thread/c7...
> 2) Java String versus Byte[] -
> seehttp://groups.google.com/group/cryptopp-users/browse_thread/thread/8b...
> 3) Verify your use of Java's Str::getBytes() -
> seehttp://groups.google.com/group/cryptopp-users/browse_thread/thread/12...
>
> Jeff
>
> On 3/14/08, UnFleshed One <[EMAIL PROTECTED]> wrote:> Geoff Beier wrote:
> > const byte KEY[] = {
>
> 48, -126, 1, -72, 48, -126, 1, 44, 6, 7, 42, -122,
>
>
>
> > 72, -50,
> > This jumps out at me immediately; I suspect you've not exported your
> key
> > properly.
>
> A byte is an unsigned type. -126, -72, etc. don't make sense.
>
> > Signed char -126 is 130 when converted to unsigned char (256 - x). So
> > assuming original byte was 0x82 that's perfectly fine.
>
> > Ronald, I never used DSA, so I can't tell if you use it correctly, but one
> > thing you can try is create a signature using Crypto++, encode it into b64
> > same way you get it from java, and then verify it using your code. That way
> > you can eliminate at least one of possible errors (it is obvious thing, but
> > just in case you didn't think about it yet :)).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [EMAIL PROTECTED]
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
