There are two kind of signature schemes, ones that hide the message
and ones that do not, but basically the point of the signature scheme
is to verify who signed the message, not to conceal its contents.
ECDSA is one of those signature schemes that does not hide the
message. The signature is just appended to the message, like a real
signature at the bottom of a letter (assuming you send your snail
mail in plaintext? :-) ). ECDSA does include a hashing step, but this
does not hide the message - I think it is supposed to prevent the
usage of 'nearly identical' messages from making it easier to break
the key.
Now, when you say VerifyMessage on the signature and a /constant/
public message - there I think you have /one/ problem, which is the
constant public message. If you mean that the message never changes,
then all signatures, while each signature is different because of
random component of the signing process, there is nothing to stop
people swapping signatures. i.e. people can trade product keys. But
otherwise, yes, that is the right idea.
Also, yes, ECDSA can be made to work with smaller keys, which would be
nicer as product keys. But you are trading off security - if you cut
the signature size down by half, you are making it many orders of
magnitude easier to break by brute force.
On Sep 20, 3:42 pm, kanis <[EMAIL PROTECTED]> wrote:
> I put together some test code to generate a 28 byte (224bit) signature
> on a constant public message using ASN1::secp112r1(), and I have two
> questions.
>
> First, is calling VerifyMessage (initialized with the public keys) on
> the signature and a constant public message enough to verify that the
> signature represent a valid product key that can't be generated
> without knowledge of the private key? I don't understand if making
> the message public is a security risk, or if I need to add a hash or
> something to the product key like I've seen mentioned in a couple
> places.
>
> Second, will ECDSA work with curves of fewer bits than secp112? I'd
> rather use a smaller curve to get a shorter signature so the product
> key isn't so long, but when I used a smaller curve generated with
> Elliptic Curve Builder, I get the error "Crypto++ Error:
> CryptoMaterial: this object contains invalid values" when SignMessage
> is called.
>
> Thanks, and I hope these are easy questions for the experts out there,
> cause I've been having a hard time finding much information on this
> subject.
>
> Here's the test code I'm working with:
>
> ECIESNullT< CryptoPP::ECP >::PrivateKey PrivateKey;
>
> /*
> This is the curve generated by Elliptic Curve Builder that works with
> ECIESNullT< CryptoPP::ECP >::Decryptor Decryptor( PrivateKey );
> but not with ECDSA< CryptoPP::ECP >::Signer signer(PrivateKey);
> CryptoPP::Integer p("147088164709569533");
> CryptoPP::Integer a("6094329446842148");
> CryptoPP::Integer b("-57162508610850246");
> CryptoPP::Integer n("147088163948218061"); // R from ECB
> CryptoPP::Integer h("1"); // S from ECB, must be
> <= 4
>
> CryptoPP::Integer x("71002669261090523");
> CryptoPP::Integer y("11469141678568184");
>
> CryptoPP::AutoSeededRandomPool rng;
> CryptoPP::ECP ec( p, a, b );
> PrivateKey.Initialize( ec,CryptoPP::ECP::Point( x, y ), n , h );
> */
>
> PrivateKey.AccessGroupParameters().Initialize(ASN1::secp112r1());
> PrivateKey.SetPrivateExponent(CryptoPP::Integer("4127861661178866478914975717021461"));
> CryptoPP::ECDSA< CryptoPP::ECP >::Signer signer(PrivateKey);
> ECDSA<ECP>::Verifier verifier(signer);
>
> // sign
> byte message[] = "test";
> unsigned int messageLen = sizeof(message);
> SecByteBlock signature(signer.MaxSignatureLength(messageLen));
> AutoSeededRandomPool rng;
> unsigned int signatureLen = signer.SignMessage(rng, message,
> messageLen, signature);
>
> // verify
> std::cout << "Verify: " << verifier.VerifyMessage(message, messageLen,
> signature, signatureLen) << "\r\n";
--~--~---------~--~----~------------~-------~--~----~
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.
-~----------~----~----~----~------~----~------~--~---
