暗号を多用するアプリケーションを作成しています。ほとんどのネットワーク化されたアプリケーションと同様に、私のものはデータをさまざまな種類のメッセージ (インスタント メッセージ、ファイル チャンク、ビデオ フレームなど) に分割し、改ざん防止と正しい発信元の両方について、それぞれの信頼性をチェックする必要があります。これまでのところ、ECDH を使用して、AES で既に使用している共有シークレットをネゴシエートできます。もちろん、同じ共有シークレットを後で使用できます。
私の質問は次のとおりです。この場合、ECDH によって HMAC で確立された共有秘密を単に使用するのではなく、各メッセージに署名するために ECDSA を使用することに追加の利点はありますか?
以下で M と言う場合、暗号化されたメッセージまたは平文のいずれかを意味します。それは問題ではありません。以下のエラーを修正してください。
ECDSA (または DSA) では、通常M、安全なハッシュ アルゴリズム (私は現在 SHA-2 の 1 つを使用しています) を使用してメッセージ ( ) をハッシュし、署名者の秘密鍵を使用してH(M)暗号化することを理解しています。H(M)これによりR、S整数 (署名) が生成されます。次に、M、R、および S が、送信者の公開鍵を既に所有している受信者に送信されます。 が計算され、 と を使用しH'(M)て署名が検証されます。BouncyCastle は、これを実装するものを提供します。RSECDSASigner
HMAC では、私が持っている共有シークレットが必要です。次に:
HMAC(K, M) := H( f2(K) || H(f1(K) || M) )
(訂正していただきありがとうございます、Paŭlo Ebermann。詳細については、彼の回答を参照してください。)
では、DH/ECDH が共有シークレットを安全にネゴシエートすることを考えると、HMAC を使用してはいけない理由はありますか?
関連: なぜNSAは、MAC ではなく DSA の標準アルゴリズムを指定するのですか? SHA-2 + AES にできるという理由だけで？
ここでは速度が重要です。現在作成しているこの 1 つのプロトコルで、現在のテキスト メッセージだけでなく、近い将来、大きなファイルやビデオ フレームもサポートするようにしたいからです。したがって、私は HMAC を使用することを好みますが、上記の目標を確実に達成できるようにしたいと考えています。
ご協力いただきありがとうございます！