強力なハッシュによって暗号化されたデータの整合性を保護する理由
SSHプロトコルについて考えてみましょう。SSHパケットは[data、SHA1（data）]のようなものです。パケットはブロック暗号によって完全に暗号化されます。問題は、なぜパケットの一貫性を保護するために強力なハッシュが必要なのかということです。 IMO、単純なXORすべてのブロックのSHA1チェックサムと同じくらい安全です。データとチェックサム自体は暗号化されており、暗号化されたデータに小さな変更があれば、少なくとも1つのブロック全体が変更されます（暗号化モード（CBC）とその事実により、ハッシュはパケットの最後に格納されるため、ハッシュも予期せず変更されると思います。したがって、単純なXOR =はSHA1と同じで、SHA1の代わりにXORを使用すると、CPUを節約できます。なぜでしょうか。
例を見てみましょう。簡単にするために、サイズ4hexaのブロックを考えます。
さらに簡単にするために、次のオープンテキストを検討してください。0000 0000 0000すべてのブロックが同じであるため、XORは0000になります。
したがって、パケットは0000 0000 0000 0000で、最後の「0000」はxor-checksumです。
暗号化された場合：a840 ff70 0030 bbb5
攻撃者はメッセージを復号化できませんが、どうにかしてメッセージを変更して、私がそれを認識できないようにしたいと考えています。彼はそれをどのように行いますか？
彼が1ビット変更した場合...うーん... 3番目のブロック：
a840 ff70 0031 bbb5
しかし、復号化しようとするとどうなりますか？
0000 0000 a722 52e3
失敗しました！
私が彼にできる唯一のことは、BLOCK_nが各ブロックのBLOCK_0 xor ... xor BLOCK_（n-1）と等しい場合に備えて、ブロックをドロップできることです。パケットのヘッダーにパケット長を追加すると、そこにセキュリティホールが表示されません。
厳密に言うと、それは「一貫性」ではなく「完全性」に関するものです。つまり、Bが受信するデータはAが送信したデータと同じです。
XORは単純で可逆的な操作であり、暗号化されたデータに対しても多くの攻撃ベクトルが可能です。攻撃者は、たとえば暗号文の1ビットを0から1に、別の1ビットを1から0に変更する可能性があり、これはXORによって検出されない可能性があります。
この攻撃は多かれ少なかれさまざまな種類の暗号に適用できますが、ストリーム暗号の場合、実行するのは簡単です。したがって、この種の攻撃に影響されない特定の暗号セットに制限されていない場合は、他の手段（MAC）によって整合性を確保する必要があります。
攻撃者が暗号化されたデータストリームに任意のデータを導入できない場合でも、検出されずに転送中の情報を破壊することはできません。
単なる推測ですが、XORはデータの欠陥を検出するのに優れた方法ではないため、何かをチェックサムするための優れた方法ではありません。XOR =各ブロックで、同じ位置の2つのブロックにビットエラーがある場合、最終的なXOR値は、エラーがなかった場合と同じになります。ハッシュチェックサム、小さな変更は最終的なチェックサム値に反映され、データ内の何かが台無しにされていることを示す強力なインジケータになります。
編集：zedman9991は正しい応答を持っています。 SSHがTCPまたはUDPにラップされていることを忘れていました。どちらもデータの整合性のために独自のチェックサムを提供します。つまり、SSHデータのハッシュは、特に不規則性と防止の両方に向けられています。リプレイ攻撃の。
プレーンテキストブロックをXORするだけでは、一部の種類の攻撃を防ぐことはできません。
例えば：
メッセージの最初または最後のブロックがすべてnullバイトで構成されている場合は、IVを削除するだけで（最初の暗号化ブロックはIVと見なされます）、最後の暗号化ブロックを削除しても、メッセージは引き続き有効と判断されます。
同様に、最初の2つまたは最後の2つのブロックが同一の場合、送信の最初の2つまたは最後の2つのブロックを削除できます。
プロトコルは、実際には[data、HMAC-SHA1（data）]（またはSHA-1の代わりに別のハッシュを使用）に似ています。ここで必要なのは、データを認証すること、つまり、特定の秘密鍵を知っているソースからのものであることを保証することです。ハッシュを使用すると、受信者はデータが他のものと等しいことを確認できますが、受信者と比較するものは何もありません。対照的に、 [〜＃〜] mac [〜＃〜] を使用すると、秘密鍵を知っているエンティティーによって生成されたことを受信者が確認できます。
ブロック暗号の上にMACを構築しようとしています。これは可能ですが、あなたはそれを間違っています。あなたがするように、データがCBCモードでブロック暗号で暗号化されていると仮定しましょう。
データとチェックサム自体は暗号化されており、暗号化されたデータに少しでも変更を加えると、少なくとも1つのブロック全体が変更される可能性があります（攻撃者によって予期せずに）。
そのとおりです。1つのブロックが予期せず変更されます。ただし、これでは十分ではありません。他のブロックの結果を確認する必要があります。
暗号化モード（CBC）と実際には、ハッシュはパケットの最後に格納されます。ハッシュでさえ予測できないほど変化すると思います。
いいえ、攻撃者が注意を払っていれば、ハッシュは予期せず変更されません。実際に、選択したハッシュを変更することは非常に簡単です。これは、すべてのブロックのXORです。CBCは内部でXORを使用するため、これは必要ありません。完全に驚きました。
3つのブロックP₁、P₂、P₃およびチェックサムP₊で構成されるメッセージをCBCで暗号化し、C₁、C₂、 C₃、C₊は対応する暗号文です。ブロック暗号化関数にはEを、復号化にはDを記述します。
C₁ = E(P₁ ⊕ IV)
C₂ = E(P₂ ⊕ C₁)
C₃ = E(P₃ ⊕ C₂)
C₊ = E(P₊ ⊕ C₃) where P₊ = P₁ ⊕ P₂ ⊕ P₃
受信側は、
P₁ = D(C₁) ⊕ IV
P₂ = D(C₂) ⊕ C₁
P₃ = D(C₃) ⊕ C₂
P₊ = D(C₊) ⊕ C₃
中間者攻撃者がC₁とC₂を反転させます。受信者に表示される内容は次のとおりです。
P₁' = D(C₂) ⊕ IV
P₂' = D(C₁) ⊕ C₂
P₃' = D(C₃) ⊕ C₁
P₊' = D(C₊) ⊕ C₃
P₊' = P₊ — CBC暗号文の摂動は、摂動後の次のブロックまでしか効果がなく、残りは影響を受けないことに注意してください。そして
P₁' ⊕ P₂' ⊕ P₃' = D(C₂) ⊕ IV ⊕ D(C₁) ⊕ C₂ ⊕ D(C₃) ⊕ C₁
P₁ ⊕ P₂ ⊕ P₃ = D(C₁) ⊕ IV ⊕ D(C₂) ⊕ C₁ ⊕ D(C₃) ⊕ C₂
ああ、見て、これらは同じです。変更されたメッセージのチェックサムは正しいです。
CBCに基づいてMACアルゴリズムを設計することは可能ですが、これよりも注意する必要があります。素朴な CBC-MAC は、長さで遊んで、気づいた種類の攻撃を可能にします。この問題がないバリアントがあります。ただし、問題があります。CBC暗号化とCBC-MACに同じキーを使用しないでください。これは、同じキーを使用し、攻撃者が平文の一部を制御できる場合、攻撃者は送信者に自分のMACを計算させることができるためです。たとえば、1ブロックメッセージのCBC-MACは、そのブロックを暗号化した結果にすぎません。したがって、攻撃者が1ブロックのメッセージを送信したい場合、攻撃者がしなければならないことは、そのブロックで始まるメッセージを送信者が暗号化して結果を読み取るように手配することだけです。同じ計算を2つの異なるものに使用することは危険であるというのは一般的な原則です。これにより、同じ計算でデータが生成され、キーの使用の1つでは公開され、他の使用では非公開でなければならないデータが生成されます。
XorはMACと同等ではありません。実際、最初に認証タグを[data、SHA1（data）]として読み取っても機能しません。これは、 ハッシュのCBC暗号化は安全ではない です（xorを使用する場合よりも欠陥が微妙です） 、しかしそれは存在します）。