ECDH shared secret doesn't match in loop, with Crypto++

Question

CryptoPP::OID CURVE = CryptoPP::ASN1::secp256r1();
CryptoPP::AutoSeededRandomPool prng;
std::vector<kpStruct> KPVecRSU;

(loop begin)
kpStruct keyP;
CryptoPP::ECDH < CryptoPP::ECP >::Domain dhA( CURVE );
CryptoPP::SecByteBlock privA(dhA.PrivateKeyLength()), pubA(dhA.PublicKeyLength());
dhA.GenerateKeyPair(prng, privA, pubA);
CryptoPP::SecByteBlock sharedA(dhA.AgreedValueLength());
keyP.sharedECDH = sharedA;
KPVecRSU.push_back(keyP);
(loop end)

I want to create shared secret between 3 units, but this code give me different ones ! any idea please ?

Answer 1

ECDH shared secret doesn't match in loop, with Crypto++

Each run of the protocol produces a different shared secret because both the client and server are contributing random values during the key agreement. The inherit randomness provides forward secrecy, meaning bad guys cannot recover plain text at a later point in time because the random values were temporary or ephemeral (forgotten after the protocol execution).

In the Crypto++ implementation, the library does not even make a distinction between client and server because there's so much symmetry in the protocol. Protocols with too much symmetry can suffer the Chess Grand-Master attack, where one protocol execution is used to solve another protocol execution (think of it like a man-in-the-middle, where the bad guy is a proxy for both grand-masters). Often, you tweak a parameter on one side or the other to break the symmetry (client uses 14-byte random, server uses 18-byte random).

Other key agreement schemes we are adding do need to make the distinction between client and server, like Hashed MQV (HMQV) and Fully Hashed MQV (FHMQV). Client and Server are called Initiator and Responder in HMQV and FHMQV.

---

I want to create shared secret between 3 units, but this code give me different ones.

This is a different problem. This is known as Group Diffie-Hellman or Multi-party Diffie-Hellman. It has applications in, for example, chat and broadcast of protected content, where users are part of a group or join a group. The trickier part of the problem is how to revoke access to a group when a user leaves the group or is no longer authorized.

Crypto++ does not provide any group DH schemes, as far as I know. You may be able to modify existing sources to do it.

For Group Diffie-Hellman, you need to search Google Scholar for the papers. Pay particular attention to the security attributes of the scheme, like how to join and leave a group (grant and revoke access).