CBCモード(ディフューザー付き)に対するXTSの利点は何ですか?
On 11月 30, 2020 by adminディフューザーを備えたCBCと比較したAES-XTSの「利点」を理解するのにいくつか問題があります。
について何か読んだdiv id = “f481ea3408″>
FileVault 、このペーパーでは、XTSとCBC(ディフューザー付き)の2つの操作モードと、XTSの利点について説明します。
両方のモードで暗号化データユニットはほぼ同じ方法です。 CBCの場合、セクター番号はIVの構築に何らかの形で使用されます。XTSの場合、「微調整値」があり、これには(何らかの方法で)ブロックオフセットも含まれるため、各データブロックを個別に暗号化できます(ハードドライブを暗号化する場合に意味があります/パーティション)。 XTSの利点を実際に理解することはできません。
現在、XTSについて次のように書いています。
他の方法に比べていくつかの利点があります。 CBCのAESなど:初期化ベクトルは必要ありません(微調整キーはブロック番号から取得できます)。各ブロックは異なる方法で暗号化されます(微調整値が異なるため)。また、AES-CBCとは異なり、AES-XTSは、暗号化された微調整の異なるシフトバージョンで各AES入力を排他的論理和することにより、攻撃者がデータユニットの特定のビットを変更するのを防ぎます。
XTSとCBC(ディフューザーなし)を比較しているだけかもしれません…もしそうなら、誰かがXTSの利点を知っていますか?
そして誰かが2番目の利点を説明できます:「AES- XTSは、各AES入力を暗号化された微調整の異なるシフトバージョンで排他的論理和することにより、攻撃者がデータユニットの特定のビットを変更するのを防ぎます。 “?
コメント
- 何' s " diffuser "? "セクター番号はどういうわけか"どうですか? 'スキームを明確に説明していません。アルゴリズムが予測可能である場合、これは弱点につながり、予測不可能なアルゴリズムは高価です。
- @CodesInChaos参照はMicrosoft 'の使用されているElephantディフューザーへの参照だと思いますBitLocker内( download.microsoft.com/download/0/2/3/… —警告:PDFをダウンロード。
- Cryptography StackExchangeへようこそ。あなたの質問は、ソフトウェア開発(スタックオーバーフローのトピック)に直接関係しておらず、ここでより話題になっているため、ここに移行されました。コメントして回答を受け入れるには、ここでもアカウントを登録してください。
回答
XTSと拡散されていないCBC。ここでの問題は柔軟性です。 XTSとCBCはどちらも、攻撃者が暗号化されたデータに関する情報を学習するのを防ぎます。ただし、どちらも、攻撃者が暗号化されたデータを改ざんするのを完全に防ぐことに成功していません。
ただし、(拡散されていない)CBC暗号文を改ざんする方が間違いなく簡単です。 XTS暗号文を改ざんします。攻撃者がたまたまメッセージを知っているとしましょう。
“blah blah Give Alice \ $ 400 … blah blah
このメッセージがCBCを使用して暗号化されている場合、攻撃者は暗号文を改ざんして復号化できるようになります
“blah blah!^%@ ^^ Give Alice \ $ 800 blah blah blah”
\ $ 400は\ $ 800になりました。これは、「AES-XTSは、攻撃者がデータユニットの特定のビットを変更するのを防ぐ」という引用です。ここでは、!^%@ ^^と記述して、前の16バイトのブロックが復号化されるとギブリッシュになり、このギブリッシュが攻撃者の制御を超えてしまうことを示します。
一方、XTSを使用する攻撃者は、16バイトのブロックをランダムなジブリッシュに変えることでメッセージを破壊できますが、CBCの例と同じ程度の制御はできません。
しかし、マイクロソフトはとにかくXTSを使用しないことを決定しました。その理由は、16バイトのブロックを破壊する能力が依然として損害を与える可能性があるためです。リンクされた紙のdchestからの引用は次のとおりです。
たとえば、0に設定すると、OSにセキュリティホールを作成する値を持つ構成ファイル(またはレジストリエントリ)が存在する可能性があります。ディスク上の設定は「enableSomeSecuritySetting = 1」のようになります。値の先頭が16バイトの境界にあり、攻撃者がプレーンテキストの値をランダム化した場合、最初の2バイトが $ 2 ^ {16} $ の可能性があります。平文の0x300x00は、ASCII値「0」をエンコードする文字列です。
(この引用はLRWの調整可能な暗号を参照しています。ただし、XTSで使用されるXEX調整可能暗号にも同じ問題があります。
ディフューザーの追加。使用ディフューザーは、この問題に対するMicrosftのソリューションです。ここでの考え方は、暗号化する前に平文を「混合」して、攻撃者が\ $ 400を\ $ 800に変更できないようにすることです。暗号文の一部をいじると、平文の一部だけでなく、ほぼ全体が変更されます。
これは良さそうに聞こえますが、問題があります。Microsoftのディフューザーが実際に安全かどうかは誰にもわかりません。私の知る限り、暗号文作成者から正式な分析は公開されていません。これは、あなたがそれに依存することに懐疑的であるべきであることを意味します。 Microsoftはこれを認めています:
不利な面では、ディフューザーは新しい証明されていないアルゴリズムであり、これは必然的に疑問につながります。アルゴリズムの広範な公的な精査と分析がなければ、そのセキュリティについては正当な懐疑論があります。人々は新しいアルゴリズムを信頼することに消極的です。では、なぜこのオプションを選択したのでしょうか。最終的な分析では、これが当社の製品にとってより良い選択であると判断しました。代替案に対するパフォーマンスの向上は、新しいディフューザーアルゴリズムの欠点を上回るのに十分重要でした。正しい選択をしたかどうかは時が経てばわかります。
要点。 XTSは、拡散されていないCBCよりも順応性が低くなります。ただし、CBC + Diffuserは、少なくとも実用的な目的では、XTSよりもおそらく順応性が低くなります。
重要なことは別として。 CBCもXTSも、非可鍛性になるように設計されていません。暗号文が改ざんされていないことを確認することは別の問題であり、HMAC-SHA256などのメッセージ認証コード(MAC)を使用して解決する必要があります。 MACがフルディスク暗号化アルゴリズムに通常使用されない理由は、(1)パフォーマンスの問題、および(2)MACを使用するには暗号文とともに追加情報を保存する必要があるため、透過的に追加するのが少し難しいためです。
MACとディフューザーの中間点は、CMC、EME、HEHなどのワイドブロック暗号化モードを使用することです。これらは「組み込み」ディフューザーを備えていると考えることができます。 Microsoftのディフューザーとは異なり、これらのアルゴリズムには正式なセキュリティ定義とピアレビューされた数学的証明があります。これらは、AESが安全であるという前提の下で安全です。 Microsoftは、(1)パフォーマンスの問題と(2)特許のために、これらを使用しないことを選択しました。
コメント
- ディスク暗号化のコンテキストでは単純ですMACは'十分ではありません。 '認証されたルートを持つハッシュツリーが必要です。
- このすばらしい回答に感謝します!!!これですべてが明確になりました… 5 *****
- おそらくこれは'は機能しませんが、'異なるパスワードや異なるアルゴリズムを使用して同じデータを2回暗号化することで、可鍛性の問題を解決できますか?したがって、実績のないディフューザーアルゴリズムを使用する代わりに、実績のあるAESを再度使用しませんか?
- @YuraこれはAESの使用方法によって異なります(たとえば、XTSは通常AESの上に構築されます)。 CTR-AESモードを2回使用した場合、結果は'順応性が低下しません(暗号文のビットを反転しても、平文の対応するビットが反転します)。 CBC-AESモードを2回使用する場合でも、私の回答で述べたのと同じ攻撃を行うことができますが、制御されていないランダムな"ガベージの長さ"セクションが2倍になります。最後に、安全な" wideblock "モードでAESを使用すると、いずれにせよ、これらのソリューションのいずれかとほぼ同じ速度になります。代わりに、そうすることもできます。
- 更新:Windows 10には、XTSモードを使用するオプションがあります。さらに大きい/悪い更新:Windows 8では、Microsoftはディフューザーを削除しました。したがって、Windows8ビットロッカーには'ディフューザーすらありません。
コメントを残す