パート3:デジタルガーリック



公式I2Pドキュメントの翻訳の第3部。

テキストにさらに近い。

誰かが知識を持っていない場合は、katにようこそ、目次を読んでください。



目次:

パート1:「知りたいこと、I2Pについて質問することを恐れていたすべてのこと」

パート2:トンネルマジック、NetDB、およびプロトコルジャグリング

パート3:デジタルガーリック



暗号化



暗号化プリミティブの最小限のセットが追加され、I2Pのさまざまな脅威に対するマルチレベルの保護が提供されます最低レベルでは、ルーター間の相互作用はトランスポートレベル(TLS)で保護されます。 このために、SSUプロトコル(安全な半信頼UDP)が使用され、各パケットは、明示的な初期化ベクトル(IV)とメッセージ認証コード(HMAC-MD5-128プロトコルを使用)でCBCモードのAES256を使用して暗号化されます。 Diffie-Halmanアルゴリズムを使用して、2048ビットのセッションキーが最初に作成されます。 ルーター認証はDSAを使用して実行され、各ネットワークメッセージには追加の整合性チェックがあります。 トンネル内のメッセージには、明示的なIVおよびSHA256ハッシュアルゴリズムを使用した整合性チェックを使用した独自のAES256 / CBC暗号化もあります。 他のメッセージもニンニク内部のネットワークを通過しますが、ElGamal / AES + SessionTagsアルゴリズムを使用して暗号化されます(以下を参照)。



「正直なメッセージ」



オニオン暗号化の継続である正直なメッセージを使用すると、1つのメッセージに多くの添付ファイル(「クローブ」)を含めることができます。 メッセージはどこかに送信されるたびにニンニクに包まれます。そうでない場合、メッセージの内容は中間ノードに表示され、これは許可されません。 例として、次の状況:

ルーターは、トンネルの作成に参加するために別のルーターに要求を送信します。これにより、メッセージは「ガーリック」暗号化でラップされ、El-Gamalスキームに従って2048ビットの公開鍵を受信し、トンネルを介してメッセージを送信します。

別の例では、クライアントが受信者にメッセージを送信する場合、「送信者」ルーターはメッセージデータを(他のメッセージと一緒に)ニンニクでラップし、受信者のleaseSetで公開されたEl Gamalスキームに従って2048ビットの公開鍵を使用してニンニクを暗号化し、送信します対応するトンネル。



セグメントに含まれるネストされた命令により、ローカル(どこか)、リモートルーター、またはリモートルーターへのトンネルにリダイレクトできます。 指示には特別なフィールドがあり、特定のトリガーが起動するまで(時間または条件によって)ピアに配信を延期することができます。「非自明な遅延」(人為的に作成された遅延)内に実行されない場合、メッセージは「デプロイ」されます(デプロイされます)。

可能であれば、事前にトンネルを構築することなく、ニンニクメッセージを任意の数のホップ(ジャンプ-中間ポイント)経由でターゲットに送信できます。 ニンニクになると、所定のステップ数を経て、トンネル内の次のホップに届けられます。

(およそ。-私が理解しているように、これは重要な遅延の例です)。

現在のネットワークおよびクライアントの実装では、このメソッドは使用できません。



セッションタグ



I2Pベースのシステムからの信頼できない混乱したメッセージとして、I2Pは非対称および対称暗号化アルゴリズムの単純な組み合わせを使用して、ニンニクメッセージに埋め込まれたデータの機密性と整合性を保証します。 この組み合わせはEl Gemal / AES + SessionTagsと呼ばれますが、2048ビットの「ElGamal」、AES256、SHA256、および32バイトのワンタイム番号に使用される単純なアルゴリズムを説明する非常に詳細な方法です。



最初に、ルーターはAES256を使用して別のルーターのメッセージを暗号化し、ElGamalがキーとして機能し、その後、AES256 / CBC暗号化された「有用な」(追加、トランジット)負荷が追加されます。 追加の負荷では、暗号化されたAESセクションには、負荷の長さ、SHA256ハッシュ、暗号化されていない負荷、およびランダムな32バイトのセッションタグが含まれます。 次回、送信者は別のルーターの「ニンニク」を暗号化したいが、ElGamalを使用して新しいキーを生成せずに、以前に設定したセッションタグとAESペイロード暗号化のいずれかを選択できます。以前に追加されました。 ルーターはメッセージを受信すると、最初の32バイトをチェックして使用可能なセッションタグと一致するかどうかを確認し、一致する場合は単純なAES復号化を使用しますが、一致しない場合はElGamalアルゴリズムを最初のブロックに使用します。



各セッションタグは、内部競合を防ぎ、ルーター間でメッセージを相互に関連付けるために1回だけ使用できます。 ニンニクメッセージを使用すると、配信ステータスを監視できます。配信が成功すると、トリガーが実行されます。

受信者にヒット->復号化に成功->返信応答の指示を検索し、見つかった場合は、着信トンネルを介して送信者に返事を送信します。

送信者は、配信ステータスメッセージを受信すると、メッセージ内のセッションタグが正常に配信されたことを知ります。 セッションタグは、それ自体では寿命が非常に短く、寿命が切れると使用されない場合は削除されます。 また、キー自体の数と同様に、各キーの保存回数も制限されています。 タグが多すぎる場合、新しいものまたは古いものを「捨てる」ことができます。 送信者はセッションタグを使用してメッセージを追跡します。必要な接続がない場合は、メッセージを開く前に削除でき、El-Gamalの暗号化によりメッセージが戻ります。



(注:PRNG-擬似乱数ジェネレーター)

1つのオプションは、1つのタグを送信し、PRNGをリッスンして、使用されたタグと使用可能なタグを判別することです。

送信者と受信者の間でPRNGをほぼ同期した状態に保ちます(受信者は次のウィンドウのサイズ、たとえば50タグを計算します)。オーバーヘッドが大きすぎると、タグが削除されます。

それでも、内部の敵に対する保護の程度はPRNGの複雑さに依存します。PRNGの使用回数を制限することにより、弱点を最小限に抑えることができます。 しかし、現時点では、近い将来、同期PRNGの開発に移行する計画はありません。



All Articles