On Tuesday, March 10, 2015 at 6:14:04 AM UTC-4, [email protected] 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> ¶ms =
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
--
--
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.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
