セキュアリモートパスワードプロトコルの最後にある認証はどれですか。
クライアントとサーバーが同じプレマスター共有キーを持っていることを互いに証明するには、 元の作成者 がこれを示唆しています。
_M = H(A | B | K) -->
<-- H(A | M | K)
_RFC 2945 はこれを推奨しています：
_M = H(H(N) XOR H(g) | H(U) | s | A | B | K) -->
<-- H(A | M | K)
_これらの連結のいくつが実際にセキュリティを向上させますか？また、セキュリティを低下させることなく、どの程度の自由度で変更する必要がありますか？たとえば、XORを連結で置き換えるのと同じくらい安全であると思います。
- A-公開、毎回ランダム、クライアントが決定
- B-パブリック、毎回ランダム、サーバーによって決定
- U-私の実装ではプライベート、ユーザー名（ソルトハッシュとソルトはパブリックです）
- s-サーバーによって決定された、ユーザーアカウントのパスワードに関連付けられたパブリック
- Nおよびg-プログラマーによって決定されるパブリックの定数
- K-プライベート、毎回ランダム、サーバーとクライアント間の秘密鍵
どの定義を使用する必要がありますか？ 2つの違いは、サーバーによって決定されたより多くのパブリック値が2番目のハッシュに連結されることです。攻撃者はH(N) XOR H(g) | H(U) | s | A | Bだけでなく_A | B_も知っているので、これは実際に価値がありますか？
編集：大文字のUは実際にはユーザー名です。小文字として読んでいました。明らかに、C＃の大文字と小文字の区別はそれほど大きくありません。
「これらの連結のいくつが実際にセキュリティを向上させますか？」
セキュリティ上、私はあなたがKの機密性を意味すると思います。
Kは直接送信しないことで保護されています。安全でないチャネルでKを平文として送信すると、明らかに傍受され、Kを使用した暗号化は危険にさらされます。
Kを暗号化して送信することもできますが、これには別のキーが必要であり、どこにもアクセスできません。
したがって、プロトコルはKのハッシュバージョンを送信します。ハッシュは、ブルートフォースまたはレインボーテーブル攻撃を使用して無効にすることができます。 H(K)が送信された場合、H(K)への攻撃が成功すると、攻撃者にKが明らかになる可能性があります。ハッシュの衝突がある可能性があるため、 H(K)への攻撃が成功すると、K以外の値が生成される可能性があります。ハッシュに入力データを追加すると、試行する値のドメインが大きくなるため、ハッシュへの攻撃が困難になります。ハッシュへの入力が大きいほど、攻撃を成功させるのが難しくなります。そのため、すべての連結によってセキュリティが向上するというのが答えです。
「たとえば、XORを連結で置き換えるのと同じくらい安全だと想像します。」
XORの目的がわかりません。 SHA1には弱点があり、XOR of H(N) and H(g) KはB、g、x、a、u、Nの関数のハッシュなので、gとNはハッシュされ、XORされて、入力データの一部が接続されるのを防ぎます。理論的にはできるだけ多くの入力をハッシュ関数に入力し、2つの値をXORすると、2つの値を連結する場合と比較して入力データのサイズが小さくなります。Nとgは公に知られているため、XORはハッシュへの攻撃が成功した場合にこれらの値を保護します。
「セキュリティを低下させることなく、どれだけの自由度を変更する必要がありますか？
注文や操作の変更によってセキュリティが向上または低下する時期を直感的に判断することはできません。安全な想定では、変更を行うとセキュリティが低下します。セキュリティを向上させるアルゴリズムの変更についてのアナウンスの頻度と、アルゴリズムを破壊する攻撃についてのアナウンスの頻度を比較してください。アルゴリズムのセキュリティを向上させることは困難です。 MD5およびその他のハッシュ関数を壊す方法 を読んでから、作者が犯した間違いを見つけます。 MD5のWangの十分な条件は十分ではありません は、最初の論文の発見に対して少なくとも1つの論文批判的です。
SRPの最後に、クライアントとサーバーは相互に暗黙的に認証されます。 「暗黙的」とは、「共有秘密を本当に知っている人と話したかどうかはわかりませんが、共有秘密を知っている場合にのみ、プロトコルから取得した対称鍵を知っていることを知っています」という意味です。それを確認したい場合は、ピアにチャレンジしてください。対称キーを使用してください。
今では、見た目ほど簡単ではありません。特に、攻撃者はマシンに自分自身と通信させようとする可能性があります。セキュリティを確保するために、SRPによって生成されたキーからいくつかの対称キーを導出する必要があります。1つはクライアントからサーバーへ暗号化するキー、もう1つはサーバーからクライアントへ個別のキーです。また、整合性チェック用のキーのペアも。これは正しく理解するのが難しいため、長年にわたる攻撃と反撃を通じてこれらの詳細すべてが苦痛に調整されたプロトコルを使用することは強く推奨されています-すなわち、TLS。私は RFC 5054 について話しましたか？ TLSにはFinishedメッセージが含まれています。これは基本的に、私が話している課題です。マシンがピアからFinishedメッセージを受信し、それを処理できた場合（適切なMAC、解読時に適切な値）、ピアは正常にexplicitly認証されました。
Thomas Porninが述べたように、論文（暗号学者の仕様）よりもRFC（技術者の仕様）を選ぶべきです。 RFC5054が機能しない場合は、2945を使用してください。
暗号プロトコルについて私が知っていることから、値A、B、Mは、攻撃者が同じまたは他のホストとの同じ接続または並列接続でメッセージの順序とその再生を変更できないようにするために重要です。
値H(N)およびH(g)は、それらが一般的なパラメータであると思うので、元の論文では使用されていませんが、実際にはこれらのグループパラメータ一部の初期プロトコルネゴシエーションによって選択されます。したがって、パラメータが突然変化した場合、攻撃が行われる可能性があります。実際のサーバーでは、サポートされている各（g、N）または複数のベリファイアごとに、ユーザーごとに複数のSRPベリファイア値が存在する場合もあります。異なるソルト「s」のそれぞれの値です。TomWuはこれらをハッシュに統合して、プロトコルのセキュリティがこのような奇妙な設定から独立していることを保証していると思います。しかし、それは「良い形」のためだけに行いました。
多分、うまくいけば、Uの説明を修正するのを忘れただけですが、
あなたはあなたの場合Uは「プライベート」であると書いていますが、ソルトされたハッシュとソルトはパブリックです。検証値が公開されている最後のビットは非常に奇妙で、SRPでは意図されていません。公開検証値は、サーバーが侵害された後にのみ発生します。この場合、SRPは標準のハッシュベースのチャレンジ/レスポンス交換と同じくらい安全です。ベリファイアの値はオフラインのブルートフォースに対して脆弱です。
パスワード（P？）が非常に強力な場合、これは問題ではありません。それ以外の場合は、大きな問題です。どちらの場合も、標準のチャレンジレスポンスよりもよい結果が得られます。
Uを「プライベート」にすることはできません。最初のステップでクリアに転送されます。