秘密鍵の一部を公に共有することのリスクはどのくらいですか？
2人が同じ（たとえば256ビット）秘密鍵を持っていることを確認したい場合、潜在的に公開されているチャネルで最初の8文字を共有することのリスクはどのくらいですか？
攻撃者はそれらの文字だけより多くの情報を回復できますか、および/または攻撃者はこれらの8文字でキーをクラックできますか？
秘密鍵のany部分を提供すると、攻撃者が探索できる潜在的な鍵スペースが小さくなるため、少なくともわずかに安全性が低下します。
あなたが達成したいことを理解できません。 2人が同じ情報を保持しているかどうかを確認するために行う必要があるのは、ハッシュを交換することだけです。
プロトコルを設計していて、リプレイ攻撃が心配な場合は、HMACを使用してチャレンジ応答を実行することにより、プロトコルから保護できます。
編集：
コメントを提案して D.W。の洞察に満ちた答え で説明したように、私は、秘密鍵のセキュリティへの影響が、使用しているアルゴリズムの詳細に依存することを強調する必要があります。最悪の場合のシナリオでは、秘密鍵のごく一部のみを明らかにすると、その鍵のセキュリティが完全に破られます。
一部の非対称（公開鍵）暗号システムでは、秘密鍵の一部を明らかにすることは破滅的な場合があります。リスクの正確なレベルは、使用している暗号システムによって異なります。いくつかの例：
公開キーにe = 3のRSAを使用している場合、秘密キーの1/4（dの下位1/4ビット）を明らかにするだけで、攻撃者は秘密キー全体を再構築できます。たとえば、2048ビットのRSAを使用していて、秘密鍵の最下位512ビットを明らかにした場合、攻撃者は残りの秘密鍵を回復できます。この結果は、Boneh、Durfee、Frankelによるものです。文献のような他の結果があります（たとえば、最上位ビット、ビットのランダムなサブセットなど）。
DSAでは、各署名で使用されているナンスから数ビットがリークされた場合（さまざまな署名の場合）、秘密鍵を回復するにはこれで十分です。たとえば、4000の各署名で使用された5ビットのシークレットナンスを観察できる場合、それは384ビットのECDSA秘密キーを回復するのに十分です。これは秘密鍵を正確に明らかにしているわけではありません（署名中に生成された他の秘密の値を明らかにしています）が、それは似ています。
他の答えは問題ないと言っていることに気づきました。これらの答えは、対称鍵暗号システムを使用していると想定している場合があります。ほとんどの対称鍵暗号システムでは、鍵の一部を公開しても、十分な数の鍵が公開されていない場合、それらは依然として安全です。非対称暗号システムに関しては、状況は異なります。他の答えは、ブルートフォース（可能な限りすべての秘密鍵を徹底的に試す）が暗号システムに対して可能な最善の攻撃であると想定しているようです。多くの非対称暗号システムでは、この仮定は正確ではありません。
攻撃者は、これらの8文字を考えると、どれだけ速くキーを解読できますか？
どのようなキーについて話しているのか、どのアルゴリズムで使用されているのかを知らずに答えるのは難しいです。
鍵が完全にランダムである対称暗号化の場合（各ビットは鍵のグローバルな不確実性で同等の役割を果たすことを理解してください）、それは主にバイナリデータに関して「1文字」が何を表すかに依存します。一般に、_n bits_を明らかにすることで、可能なキーの数を少なくとも_2^n_の係数で効果的に削減できます。
- バイナリテキスト表現で
1 character = (0 or 1) = 1 bitの場合：8文字は、縮小係数が_2^8 = 256_であることを意味します。 - 16進数表現で_
1 character = 4 bits_の場合：8文字は、縮小係数が_2^32 = 4294967296_であることを意味します。 - _
1 character = 6 bits_のbase64表現の場合：8文字は、_2^48 = 281474976710656_の縮小係数を意味します。
明らかにされた情報の量に応じて、暗号化アルゴリズムの考えられる（現在または将来の）弱点に応じて、キーを破るレバレッジとして使用する場合としない場合があります。
また、鍵が完全にランダムではない非対称暗号化の場合（RSAの素因数モジュラスや指数など）、_n bits_を明らかにすると、実際にははるかに有用な情報が明らかになり、セキュリティの破滅的な損失につながる可能性があります。
しかし、本当の質問は：
なぜ誰もがそれをする必要があるのでしょうか？
この方法は潜在的なセキュリティ欠陥をもたらすだけでなく、信頼性が目的に適合していないようです。残りの248ビットはどうですか？
あなたが説明する方法は、完全に連続的（完全性チェックには非常に悪い）であり、部分的にリバーシブル（セキュリティ目的には非常に悪い）である非常に些細なハッシュ関数です。
本当にこれを行う必要がある場合、- SHA-256 などの安全で広く利用可能な暗号ハッシュ関数を使用します=これは、はるかにsecure（実際には不可逆的で計算集約的）およびはるかに多くのハッシュを生成します「最初の8文字」よりも衝突に強い。
非対称暗号化を使用している場合は、秘密鍵の一部（ハッシュであっても）を共有する必要はありません代わりに公開鍵を使用してください。
「8文字」の意味と使用するアルゴリズムに応じて、「重要ではないが、少し愚か」から「悲惨」までの範囲であると思います。
文字通り「8文字」を64ビットと読み取る場合、キーのサイズを64ビット削減します（「文字」をbase-64エンコード文字と仮定すると、48ビットのみになります。 ）。
「秘密鍵」が実際には対称アルゴリズムを参照していると想定すると（そうではないでしょうか？）、192ビットはブルートフォースの可能性をはるかに超えているため、おそらくそれは許容できます。しかし、再び、なぜ最初から256ビットのキーを使用するのでしょうか。
「秘密鍵、256ビット」を想定すると、一種の楕円曲線暗号を使用することを意味します（対称暗号の場合、「秘密」はすべての鍵が非公開であり、RSAなどの場合、256ビットはほとんど意味がないため、ほとんど意味がありません）あまりにも小さすぎて役に立たない場合）、セキュリティレベルを128ビットより少し低い（現在は実行不可能）から96ビットよりやや低いレベルに下げます。それは...まあ、正確には実現可能ではありませんが、ほとんどです。量子コンピューティングはまだ完全ではないが、その途上にあることを考えると、「完全ではないが、ほとんど」はちょっと悲惨です。
結局のところ、計画しているのは最良のケースではなく、最悪のケースです。
これはさらに悲惨であり、これを行うことは絶対に100％不要です。
2つのパーティが秘密鍵を共有する場合、同じ鍵であることを確認する非常に明白な方法の1つは、十分に長い（ハッシュ出力より長い）ランダムビットパターンを暗号化し、反対側でビットパターンを復号化して、安全な方法で送り返すことです。ビットパターンのハッシュ（SHA-256、SHA3など）。
最初のパーティが元のランダムパターンのハッシュを計算した結果と簡単に比較できるもの。
秘密鍵（またはその一部）が送信されることはありません。また、その鍵のハッシュ（非常に可能性は低いですが、逆にされたり、一部にヒントが提供されることもあります）はありません。出力ビットよりも入力ビットの場合、ハッシュ値からハッシュされた元のビットパターンを特定し、それを使用して暗号化の角度を取得することはできません。
攻撃者は、オリジナルを取得するために（未知の）キーを知る必要があるランダムなビットパターンと、多くのビットパターンの1つである可能性のある別の未知のビットパターンのハッシュ（どのパターンを知る方法がないか）を見るだけです。 ）。
他の人たちは、情報がどれだけ漏洩したか、そしてそれゆえ攻撃者にとってどれだけのエントロピーが低下したかについてすでに答えています。また、（公に）ハッシュを比較する必要があるという主要な点も指摘されています。
ただし、これは、鍵を比較したい2人が互いに信頼していることを前提としています。彼らがお互いを信頼しない場合、問題は、Aがhash（K）をBに送信した場合、BはAがBと同じか、または異なるKであることを認識できますが、チートして同じハッシュを送り返すことができるということです。 AにBも同じ鍵を持っていると誤って考えさせる。
その問題の解決策は、Aがhash（K）をBに送信し、Bがhash（not K）をAに送信することを期待することです。ここで、KはKのビット単位の反転値ではありません。本当にKを持っています.
[〜＃〜] note [〜＃〜]以下は、ブルートフォース攻撃で得られるような線形スピードアップを想定しています-アルゴリズムによっては、スピードアップが指数関数的に増える場合があります。
大きな数字を理解することは非常に困難です-答えが浮かび上がって驚いたとしてもです。これについての考え方は次のとおりです。
情報がなければ、8つのバイナリ文字を使用して鍵を解読するのに138億年（これまでの宇宙の年齢）がかかる場合、たったの0.023秒しかかかりません。
これは、138億年/ 2（bits_per_symbol * number_of_symbols）。
シンボルの数は「8文字」であるとおっしゃっていましたが、シンボルあたり8ビットのバイナリを想定しています。だから：138億年/ 2（8 * 8）
それらがuuencodedまたはbase64の場合、シンボルごとに6ビットになるため、残りの組み合わせを処理するのに25分かかります。
これらの比率は、明らかにしたビット数にのみ適用され、キーの長さに関係ありません（キーがクラックされるのに138億年かかる場合に限ります）。
公開鍵暗号の要点は、決して秘密鍵を共有する必要がないことです。各秘密鍵は1か所にのみ存在し、ネットワーク上を移動しないでください。キーを送信することは、公開キー暗号化の原則そのものに反します。部分的またはその他の方法で秘密鍵を送信する必要はありません。
2つ（またはそれ以上）の異なるデバイスで同じメッセージをデコードできるようにする場合は、それぞれが独自の秘密鍵を作成し、公開鍵を（安全に!!）送信してから、両方の鍵でメッセージを暗号化します。通常、PKCでは、長いメッセージはランダムなキーを使用した対称暗号化を使用して暗号化され、キーはPKCを使用して暗号化され、メッセージと共に送信されます。複数の公開鍵でランダムな鍵を簡単に暗号化し、それらすべてを同じメッセージで送信できます。
あなたがしたいすべてがあなたが秘密鍵を持っていることを示すことであるならば、あなたは以下をすることができます：
証明したい人にランダムな値（「ナンス」）を提供するように依頼します。独自のランダムな値を追加してハッシュし、ハッシュに署名します。ランダムな値と署名を送り返します。
次に、相手は送信されたnonceとランダムな値を取得してハッシュし、署名を公開鍵と照合します。
送信者からのランダムな値を含めると、実際の所有者によって以前に署名された値を選択しただけではないことが証明されます。
いかなる状況下においても、他の誰かから送信されたものを受け入れて、変更せずに署名してください。彼らはあなたが彼らが書いた文書の指紋をあなたに送ることができ、あなたはその文書に効果的に署名するでしょう。
アリスとボブが同じ秘密鍵を共有していると疑う場合は、なぜですか：
- アリスはノンスXを生成します。
- アリスはXを自分に暗号化-Y.
- アリスはX、Yをボブに送信します。
- アリスとボブが本当に同じ秘密鍵を持っている場合、ボブはYを復号化するとXを取得します。これで、ボブはアリスが自分の秘密鍵を共有していることを認識します。
- ボブは同じことを逆に行います。これで、アリスはボブが自分の秘密鍵を共有していることを知っています。
私は暗号の専門家ではありません。何か不足していますか？
上記は彼らの秘密を明らかにすることなく彼らの質問を満足させると思います。イブは質問への答えも知りません。