1 
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)

3 つのユニット間で共有シークレットを作成したいのですが、このコードでは別のものが得られます。アイデアはありますか？

4

1 に答える 1

0

ECDH 共有シークレットがループ内で一致しない、Crypto++

クライアントとサーバーの両方が鍵合意中にランダムな値を提供しているため、プロトコルの実行ごとに異なる共有秘密が生成されます。継承のランダム性は前方秘匿性を提供します。つまり、ランダムな値は一時的または一時的なもの (プロトコルの実行後に忘れられたもの) であるため、悪者は後でプレーン テキストを復元できません。

Crypto++ の実装では、プロトコルに非常に多くの対称性があるため、ライブラリはクライアントとサーバーを区別しません。対称性が高すぎるプロトコルは、1 つのプロトコル実行が別のプロトコル実行を解決するために使用される Chess Grand-Master 攻撃を受ける可能性があります (悪者が両方のグランドマスターのプロキシである中間者のように考えてください)。マスター）。多くの場合、一方または他方のパラメーターを微調整して対称性を破ります (クライアントは 14 バイトのランダムを使用し、サーバーは 18 バイトのランダムを使用します)。

Hashed MQV (HMQV) や Fully Hashed MQV (FHMQV) など、追加するその他の鍵合意スキームでは、クライアントとサーバーを区別する必要があります。クライアントとサーバーは、HMQV と FHMQV ではイニシエーターとレスポンダーと呼ばれます。

3 つのユニット間で共有シークレットを作成したいのですが、このコードでは異なるものが得られます。

これは別の問題です。これは、Group Diffie-Hellman またはMulti-party Diffie-Hellman として知られています。たとえば、ユーザーがグループに属している、またはグループに参加している、保護されたコンテンツのチャットやブロードキャストなどのアプリケーションがあります。問題のより厄介な部分は、ユーザーがグループを離れたり、承認されなくなったときに、グループへのアクセスを取り消す方法です。

私の知る限り、Crypto++ はグループ DH スキームを提供していません。それを行うために既存のソースを変更できる場合があります。

Group Diffie-Hellmanについては、Google Scholar で論文を検索する必要があります。グループへの参加方法やグループからの脱退方法 (アクセスの許可と取り消し) など、スキームのセキュリティ属性に特に注意してください。

于 2016-08-18T02:24:12.213 に答える