Verify signature using elliptic curve cryptography

I need to verify a signature of a message which contains several values. The only parameters I have are the signature, the public key and the values itself. The algorithm used for creating the signature is eliptic curve cryptography with 192 bit. I allready tried to find code examples on the net but I didn't find anything for this case.

Has anybody experiences with this algorithm using java for verificati开发者_如何学运维on? Could you please provide code or a link to an example?

Thank you for your help!

You are a bit short on information there...

There are several signature schemes which use elliptic curves, but the most widespread (by far) is ECDSA. You must then worry about the following points:

• Signature operates on a sequence of bits. Every single data bit must be correct. Here, you have "values" so there must be an encoding of those values into a sequence of bits (or bytes). To verify the signature, you must use the same encoding than the one used to generate the signature.

• ECDSA begins by hashing the input data with a cryptographic hash function. There again, you must use the same one than what was used for generating the signature. As a wild guess, I would say that the hash function is probably SHA-1.

• ECDSA operates in an elliptic curve. The curve size is not enough to define the curve: there are many 192-bit curves. However, since defining your own curve is hard, most people use one curve among the 15 curves defined in FIPS 186-3. One of those 15 curves has a "192-bit size" (it is called "P-192") so chances are that the signature uses that curve.

• An ECDSA public key is the encoding of a curve point. A curve point is, nominally, a pair of integers (X, Y) (these are the "coordinates" of the point). These integers are from the base field in which the curve lives; for the P-192 curve, the coordinates are 192-bit integers. The "normal" encoding for such a public key is then a 49-byte string: the first byte will be 0x02, followed by the big-endian unsigned encoding of X (24 bytes), then the unsigned encoding of Y (24 bytes). Other encodings are possible.

• An ECDSA signature formally consists in two integer values, usually called r and s (192-bit integers too). There again, the signature you have is probably a sequence of bytes which is an encoding of the two integers. There are two common encodings, one being a raw big-endian unsigned encoding of both value (hence a 48-byte signature), the other using ASN.1 (for a signature of length 53 or 54 bytes, or so).

Using Bouncy Castle, as @Ashkan suggests, is a good idea. But, as you see, there are quite a lot of assumptions to do about your situation. If you want to gain a thorough understanding of what is going on, buy a copy of ANSI X9.62:2005 (the ECDSA standard). Be warned that the mathematical contents are quite heavy.

You can probably use Bouncy Castle library.

See http://www.bouncycastle.org/wiki/display/JA1/Using+Elliptic+Curve