現実の世界では、ECBに対するプレーンテキスト攻撃はどのように実装されていますか？
AESに対する攻撃について調べてみると、ECBが悪い理由とその背後にあるロジックを理解できる数え切れないほどの例を見てきましたが、これらの攻撃が実際に実際にどのように機能するのか頭をつかむことができません。
したがって、私がよく使用していると思われる大きな例は、AES-ECBで暗号化されたセッショントークンであり、そのセッショントークン（Cookieなど）として、選択したプレーンテキストを繰り返し挿入して、暗号テキストの変更を監視できます。トークンは常に同じキーで暗号化されます。しかし、そこからどのようにして正しい平文を推測できるのでしょうか。
たとえば、ユーザー名として64個のAを挿入し、返されるCookieの16進ダンプに、暗号化がAES-ECBであることをかなり明確に示している、16バイトの繰り返しブロックが表示されていることを確認できます。最後の16 Aを15 AのBに変更できるので、16 Aの暗号文がどのように見えるかだけでなく、すべてのAとBの暗号文もどのように見えるかがわかります。
しかし、その後、行き詰まり、この攻撃がどのように拡大して実用的になるのかわかりません。これまでのところ私が見ることができるのは、最後のバイトがどのように見えるかを知っていることと、Aの束です。
私がこれまでに見てきた良い説明は次のとおりです： https://vimeo.com/41116595 彼は42分のマークの周りで私を失っていますが http：//www.slideshare。 net/ceng/cryptography-for-penetration-testers-pdf-version-presentation
編集：問題について考えた後、私はこの質問を表現するより良い方法は次のようになると思います-私たちが制御するブロックが暗号文の任意の長さであり、合計暗号文が任意の長さであるとすると、どのように長さを計算しますかプレフィックス（Aの数）を注入して、連続する各バイトを解読できるようにしますか？
編集：「接頭辞の長さをどのように計算するか」という質問に追加する上記の編集は、実際には不正確です。私たちが制御するnot暗号文のプレフィックス長を計算するのは簡単であり、説明したとおり、ECB攻撃は設計されていますテキストを解読するには、選択した平文の暗号文を明示的に後に来ます。
これを理解するための準備が整っているようですね。私はECBが選択したプレーンテキストを利用したことはありませんが、最近、Oracleのエクスプロイトをパディングしました。
基本的な考え方は、一度に1バイトをブルートフォースにすることです。
他のデータが挿入されていない単純な例があるので、それは "[username] [secret]"だけです。まず、ユーザー名を16 Aに設定します。次に、最後の文字をBに変更します。実際には、最終バイトの256の可能なすべての値を調べ、暗号化テキストの記録を保持します。
ユーザー名を15 Aに設定します。プレーンテキストブロックは、15 Aと、シークレットからの1バイトで構成されます。暗号文は、以前に生成した暗号文の1つと一致し、そこから秘密の1バイトを推定できます。
次に、ユーザー名を16文字の値に設定します。14Aは、知っている1バイトのプレーンテキストで、最後のバイトの256個の可能な値を循環します。すべての暗号文を記録します。次のステップは、ユーザー名を14 Aに設定することです。生成された暗号文から、秘密の2番目のバイトを推測できます。
続けてください、そしてすぐにあなたは完全な秘密を持っています！
実際のシナリオでは、悪用を困難にする他のものが存在する可能性がありますが、これが基本的な考え方です。