すべての資格情報が公開されている場合、OpenSSLのTLS-SRPは引き続きPFSを提供しますか？
PFSの明らかな頼みの綱はDHE（またはECDHE）です。
しかし、私は tls-srp ただし、固定された（したがって、公に知られていると見なすことができる）資格情報を使用すると、PFSも実現できます。 SRPの機能の1つは、秘密を知っていてもセッションキーを再計算できないことであるため、これが当てはまると思います。
背景情報：
私はOpenSSLを使用してサーバーとクライアントのコードに取り組んでいます。
認証後に暗号化されたチャネルを確立するという本来の目的のために、すでにtls-srpを使用しています。
- 現在、追加のPFSのみのチャネルが必要であり、明示的に認証を必要とせず、各セッションの暗号化されたデータを保護する必要があります。
DHEを使用することもできますが、tls-srpを再利用できれば簡単ですが、認証をバイパスするための資格情報が固定されています。サーバーとクライアントの両方を制御し、サードパーティのことを心配する必要がないので、問題はありません。 DHEを使わないことで、証明書についても心配する必要がなくなると思います。
これが良い考えではない場合はお知らせください。コメントは大歓迎です。どうもありがとうございました。
これは良い考えではありません。しかし、それはSRPの問題ではありません。
[〜＃〜] srp [〜＃〜] は パスワード認証鍵交換プロトコル であり、これにより2者は別の共有シークレットを介した相互認証。このことの利点は、最初の共有シークレットが弱い可能性があることです（つまり、人間のユーザーが覚えることができるパスワード）が、新しい共有シークレットはオフライン辞書攻撃の影響を受けません。
辞書攻撃は、人間と互換性のある秘密に対するブルートフォース攻撃です。攻撃者は、正しいパスワードが見つかるまで「潜在的なパスワード」を試します。 オフライン辞書攻撃は、攻撃者がターゲットシステムとそれ以上対話することなく、自宅でパスワードをテストするのに十分な情報を取得した辞書攻撃です。たとえば、攻撃者がパスワードのハッシュを持っている場合、攻撃者はパスワードをハッシュし、既知のハッシュ値と比較することでパスワードを試すことができます。オフライン辞書攻撃は、攻撃者が専用ハードウェア（GPU、FPGA、ASIC ...）、レンタルシステム（商用クラウド）、または「借用電力」（アイドル状態のマシン）を介して、タスクでより多くの電力を投入することを妨げるものがないため、強力です。大学のネットワーク、ボットネット...）。
逆に、オフライン辞書攻撃が不可能な場合、攻撃者はオンライン辞書攻撃を使用する必要があります。そうすると、正直なシステムが応答速度を制限できるため、状況は良くなり始めます。または、失敗が多すぎると応答を停止します。これは、PINを使用したスマートカードの動作です。PINをいくつか間違えると、それ自体がロックされます。
PAKEの要点は、オフライン辞書攻撃を回避することです。攻撃者は、潜在的なパスワードをテストするときはいつでも、本物のクライアントまたは本物のサーバーのいずれかと話し合う必要があります。これはあなたのケースにいくつかの結果をもたらします：
PAKEプロトコル、特にSRPは、当然、 転送秘密 （PFSとも呼ばれます）を提供します。 Forward Secrecyとは、後でいずれかまたは両方の当事者の長期保存された秘密値を盗むことができた攻撃者に対しても、過去の通信の機密性を保持することです。 TLS-SRPの場合、長期保存される秘密の値は共有パスワードのみです。
攻撃者が（受動的に）接続を記録し、後で共有シークレット（パスワード）を盗んだ後、[〜＃〜] p [〜＃〜]という手順があるとします。x）、接続の内容を解明できます。このようなプロシージャ[〜＃〜] p [〜＃〜]が存在しない場合、ForwardSecreiceが実現されます。ただし、[〜＃〜] p [〜＃〜]が存在する場合、攻撃者はそれをオフライン辞書攻撃に変えることができます。攻撃者はパスワードxを「推測」して、試行するだけです。プロシージャ[〜＃〜] p [〜＃〜]xの推測値を使用します。それが機能する場合、推測されたパスワードxは正しかった。
言い換えると、PAKEプロトコルが転送秘密を提供しない場合、機械的にはオフライン辞書攻撃に対する保護も提供しないため、「真の」PAKEプロトコルではありません。逆に、SRPのような優れたPAKEプロトコルは、必然的に転送秘密を提供します。
上記の説明は、当然、パブリックパスワードの場合にも当てはまります。公開パスワードは、辞書攻撃が本当に効率的であるパスワードです（攻撃者は最初の試行でそれを正しく取得します...）。したがって、パスワードがすべての人に知られている場合でも、転送秘密を取得できます。
ただし、これはすべて重要な詳細に依存しています。 「ForwardSecrecy」プロパティは、受動的に接続を記録し、後でそれを復号化しようとする攻撃者に関するものです。特に、アクティブ攻撃者については何も述べていません。
パスワードがすべての人に知られている場合、攻撃者は偽のサーバー、偽のクライアント、またはその両方を同時に装う可能性があります。特に、攻撃者は Man-in-the-Middle攻撃 を実行する可能性があります。このようなアクティブな攻撃者は、接続を傍受し、流れるデータをすべて見ることができます。 MitMは依然としてデータを双方向に転送するため、本物のクライアントとサーバーは賢明ではありません。
これが、この回答の冒頭で「相互」の言葉を強調した理由を説明しています。あなたが言う時：
明示的に認証は必要ありません。各セッションの暗号化されたデータを保護する必要があります。
そうすると、これは一種の矛盾です。あなたが本当に意味することは次のいずれかです：
クライアント認証は必要ありません（ただし、クライアントは適切なサーバーと通信することを保証する必要があります）。
使用状況は、攻撃者ができないアクティブになるようなものです。
実際、パッシブのみの攻撃者のコンテキストは非常にまれであり、攻撃者が転送中のデータを変更できないと単純に想定しているほとんどの人は、単なる妄想であり、ある時点で失礼な目覚めの準備ができています。つまり、ポイント1に戻ります。クライアントは、適切なサーバーと通信しているかどうかを引き続き認識できるはずです。 SRPでは、共有パスワードが相互認証の基礎になります。公開することで、認証両方向を削除しますが、削除が多すぎます。
すべてがすべての人に知られている場合、認証の概念はあり得ません。しかし、SRPは、唯一の秘密は共有パスワードであるという考えに基づいています。したがって、その唯一の秘密が実際には秘密でない場合、サーバー認証を取得することはできません。
「認証されていない」通信が必要な場合（サーバーはクライアントが誰であるかを認識していませんが、クライアントはサーバーが誰であるかを認識しています）、SRPは最適な方法ではありません。むしろ、サーバーに公開鍵と秘密鍵のペアがあり、クライアントが公開鍵を知っているか、サーバーの証明書を通じて動的に学習する「通常の」SSL/TLSを使用する必要があります（後者は証明書の検証を意味します。これはWebブラウザーが行うことですが、証明書を完全に回避することをお勧めします）。
概要：はい、パスワードが公開されている場合でも、SRPは転送秘密を提供します。しかし、いいえ、これは良い考えではありません。なぜなら、フォワードシークレットだけが本当に必要なものではないからです。また、通常の機密性も必要であり、パブリックパスワードを使用してSRPを使用すると、アクティブな攻撃者に対して機密性を維持できません。
はい。
質問を多少書き直して、「すべての資格情報が公開されている場合でもOpenSSLのTLS-SRPはPFSを提供しますか？」これがあなたの意図に反するかどうかを知らせてください。
そして、その質問に対する答えは「はい」です。
その理由は、この質問は実際には「OpenSSLのTLS-SRPはPFSを提供しますか？」と尋ねるのと同じであるためです。
Forward Secrecy（およびAFAIK[〜＃〜] pfs [〜＃〜]および[ 〜＃〜] fs [〜＃〜]は同義語です）は（ Wikipedia によって）次のように定義されます：
暗号化では、転送秘密（FS;完全転送秘密[1]とも呼ばれます）は安全な通信プロトコルの特性です。長期キーの侵害が過去のセッションキーを侵害しない場合、安全な通信プロトコルは前方秘密を持っていると言われます。
これがあなたを防御しないのは、積極的な攻撃者です。資格情報が公開されている場合、攻撃者が望むときはいつでも簡単に中間者攻撃を受ける可能性があります。ただし、たとえば、誰かが古いtcpdumpのバックアップテープを見つけた場合、長期キーはセッションキーを開示しないため、復号化できません。
免責事項：今私はSRPについてあまり知りません。基本的に私が知っているのはそれが存在するということだけです。
そして、これはここでの権威からの議論です： 知識のある人々（TM）はSRPがFSを提供すると言っています 。もしそうなら、FSの定義によれば、それはあなたが防御したい攻撃から安全でなければなりません：受動的な盗聴。