Singnature verification ECDSA secp192r1 of RIPE-MD160 hash different result comparing to BouncyCastle library

Hello,

I am new here but I use the mbedtls for years already. Now I found some strange behaviour of ECDSA signature verification using secp192r1 and RIPE-MD160 hashing algorithm. At the side of my device (Silabs EFM32GG11B320) I use mbedtls library for signing the messages and at the side of the system I communicate with there is used the bouncycastle.dll library for the signature verification.
In definitely most cases everything is correct. But sometimes I found the message which seems to me to be signed well (verified successfuly using the mbedtls compiled for PC, Windows, gcc), but the verification using bouncycastle.dll seems to be not successful. Have anyone some similar experience or advice how to decide, where the bug is? Thank you a lot for your help.

Kamil

The data of the example here:

Keypair in DER: 305F020101041804C3B80155F9BFE747BCC2A2054FBA5F7CADB52D1F6C4EFCA00A06082A8648CE3D030101A1340332000414EE967E06811AA80027F41DADBC2A2BCD59D4D842715F58FBFF6E255708E1A0D6F6B5760947C3F1113293FAF4512E91
. Loading the private key … ok
. Key information …
Q(X): 14EE967E06811AA80027F41DADBC2A2BCD59D4D842715F58

Q(Y): FBFF6E255708E1A0D6F6B5760947C3F1113293FAF4512E91

Q(Z): 01

D : 04C3B80155F9BFE747BCC2A2054FBA5F7CADB52D1F6C4EFC

ok (key size: 192 bits)

  • Public key RAW:
    0414EE967E06811AA80027F41DADBC2A2BCD59D4D842715F58FBFF6E255708E1A0D6F6B5760947C3F1113293FAF4512E91
  • Private key RAW:
    04C3B80155F9BFE747BCC2A2054FBA5F7CADB52D1F6C4EFC
  • Message ASCII: 63616268641F3837303630331F36314541313341301F3138371F301F4344351D63616268641F3837303630331F36314541313443431F3138381F301F4338321D63616268641F3837303630331F36314541313546381F3138391F301F4336361D63616268641F3837303630331F36314541313732341F3139301F301F3943331D63616268641F3837303630331F36314541313835301F3139311F301F3135351D63616268641F3837303630331F36314541313937431F3139321F301F3831411D63616268641F3837303630331F36314541314141381F3139331F301F3438461D63616268641F3837303630331F36314541314244341F3139341F301F3146351D63616268641F3837303630331F36314541314430301F3139351F301F3730361D63616268641F3837303630331F36314541314532431F3139361F301F4534391D63616268641F3837303630331F36314541314635381F3139371F301F4446311D63616268641F3837303630331F36314541323038341F3139381F301F3832351D63616268641F3837303630331F36314541323142301F3139391F301F4134321C
  • Message RAW: cabhd87060361EA13A01870CD5cabhd87060361EA14CC1880C82cabhd87060361EA15F81890C66cabhd87060361EA172419009C3cabhd87060361EA18501910155cabhd87060361EA197C192081Acabhd87060361EA1AA8193048Fcabhd87060361EA1BD419401F5cabhd87060361EA1D001950706cabhd87060361EA1E2C1960E49cabhd87060361EA1F581970DF1cabhd87060361EA20841980825cabhd87060361EA21B01990A42

. Computing message hash RIPE-MD-160… ok

  • Hash : C805D62DA600FD13A6B3A2114BD1B6AB8819BB72
    . Signing message hash RIPE-MD-160… ok (signature length = 54)
  • Signature: 303402175AD23A4D99B4DA31CCC184CE98B3DE4233174BE93E618D021900D2292DECB6F0CF11A641520200057ABABEAFA7B1CD199E48
    . Preparing verification context… ok
    . Verifying signature… ok

Solved. Just a bug in ASN.1 leading zeroes decoding…