ECMQV method and DEREncodePrivateKey

[kocu...@gmail.com]

Hello all,
first of all i am new to crypto++ but i know something about cryptography and i have managed to run your ECMQV example, but according to all documents about this algorithm in a real world party A and B, static (long term) keys' pairs are not being generated during ECMQV process and because i wanted to check if i can' give values of those keys directly from files i have generated them from via openssl terminal command. Than with PEM pack i was able to read these files and get private and public keys. Unfortunately this was not working and by displaying via openssl values of keys and in the main program i was able to discover that DEREncodePrivateKEy generates me an extra 7 bytes long buffer at the beginning of it. When i have cut this 7 bytes i was finally able to get the agreement which was correct behavior. My question now is what are those 7 bytes for (i don' know if it is always 7 but for secp256k1 curve it is always that long) and is there other way to get the real value of private key without some extra buffer?

[Jeffrey Walton]

On Tuesday, March 10, 2015 at 6:14:04 AM UTC-4, kocu...@gmail.com wrote:

Hello all,
first of all i am new to crypto++ but i know something about cryptography and i have managed to run your ECMQV example, but according to all documents about this algorithm in a real world party A and B, static (long term) keys' pairs are not being generated during ECMQV process and because i wanted to check if i can' give values of those keys directly from files i have generated them from via openssl terminal command. Than with PEM pack i was able to read these files and get private and public keys. Unfortunately this was not working and by displaying via openssl values of keys and in the main program i was able to discover that DEREncodePrivateKEy generates me an extra 7 bytes long buffer at the beginning of it. When i have cut this 7 bytes i was finally able to get the agreement which was correct behavior. My question now is what are those 7 bytes for (i don' know if it is always 7 but for secp256k1 curve it is always that long) and is there other way to get the real value of private key without some extra buffer?

To answer some of the questions (in no particular order).....

The DH-based agreement schemes use long term static keys and ephemeral keys. Crypto++ makes it difficult to export/persist the ephemeral part because they are throwaway.

If you look at the comments and the implementation, you will see the following sizes:

    unsigned int EphemeralPrivateKeyLength() const {return StaticPrivateKeyLength() + StaticPublicKeyLength();}
    unsigned int EphemeralPublicKeyLength() const{return StaticPublicKeyLength();}

And:

    unsigned int StaticPrivateKeyLength() const {return GetAbstractGroupParameters().GetSubgroupOrder().ByteCount();}
    unsigned int StaticPublicKeyLength() const{return GetAbstractGroupParameters().GetEncodedElementSize(true);}

And:

    unsigned int AgreedValueLength() const {return GetAbstractGroupParameters().GetEncodedElementSize(false);}

Here's the code to generate the ephemeral private key:

void GenerateEphemeralPrivateKey(RandomNumberGenerator &rng, byte *privateKey) const
{
    const DL_GroupParameters<Element> &params = GetAbstractGroupParameters();

    Integer x(rng, Integer::One(), params.GetMaxExponent());
    x.Encode(privateKey, StaticPrivateKeyLength());
    Element y = params.ExponentiateBase(x);
    params.EncodeElement(true, y, privateKey+StaticPrivateKeyLength());

}

void GenerateEphemeralPublicKey(RandomNumberGenerator &rng, const byte *privateKey, byte *publicKey) const
{
    memcpy(publicKey, privateKey+StaticPrivateKeyLength(), EphemeralPublicKeyLength());
}

So the shared key is just a point on the curve in uncompressed format. The preamble is probably just typical DER/ASN.1. If interested, write the buffer out to a file and see if it decodes with Gutmann's dumpasn1. If it decodes, then its DER/ASN.1.

The presentation of the keys can vary among APIs. For example, one API might use a subjectPublicKeyInfo (SPKI), another might use a DER/ASN.1 encoded Public Key, while another may use named curve and point Q. All can arrive at the same shared secret.

I'm not sure where the differences lie between OpenSSL and Crypto++ for ephemeral key agreement. I've never analyzed it or written the interop code.

Jeff