BEAST Attack：從猜測到解碼
我理解了允許攻擊者猜測先前從客戶端發送到伺服器的消息塊的 XOR 技巧：攻擊者強制客戶端發送消息 $ \tilde{m} = c_n \oplus m_g \oplus c $ 在哪裡
- $ c_n $ 是最後一個密文的最後一個塊；
- $ m_g $ 是攻擊者對先前發送消息的任意塊解密的猜測；
- $ c $ 是與真正的明文塊連結的加密塊 $ m $ （即，攻擊者試圖猜測的那個）。
當客戶端發送 $ \tilde{m} $ 到伺服器結果是
$$ E_K(c_n \oplus \tilde{m}) = E_K(c \oplus m_g) $$ 等於 $ E_K(c \oplus m) $ 當且僅當塊 $ m = m_g $ . 對消息的所有塊迭代此攻擊 $ M $ , 攻擊者可以說如果消息 $ M = M_g $ .
到目前為止，一切都很好。從現在開始我無法弄清楚的是，他如何改變他的攻擊來解密消息，而不進行猜測攻擊。特別是，問題是如果他試圖猜塊，他只有 $ 2^{-64} $ （假設使用 8 字節分組密碼）成功的機會。
解釋第二部分攻擊的文章說：“假設你已經知道 8 個字節中的 7 個字節，你只需要再猜測幾個字節（ $ 2^8 $ )”，但我不明白攻擊者如何知道他要解密的塊的前 7 個字節。
例如，這是一篇詳細介紹攻擊的文章。在最後一部分中，他給出了以下範例
GET /index.html HTTP/1.1 Host: mysite.com Cookie: Session=123456 Accept-Encoding: text/html Accept-Charset: utf-8攻擊者如何找出會話號？此消息將被加密為
GET /ind ex.html HTTP/1.1 \r\nHost : mysite .com\r\n Cookie: Session= 12345678 a7d25abbd67b2dbf e2ade7246ea5ed5 e99063ebe430b75b 746ae5eca36e2bc3 f6f62f99a076056f 6b14704973a779ae 7fa9300d4e490cba b6040b9542a59ad5 f9bb888ac3763722b目前尚不清楚（對我而言）他們是如何在文章中取得這一結果的。
我檢查過的其他資源是
（添加）免責聲明：自 2011 年以來，瀏覽器已經關閉了允許發送完全選擇的第一個塊的漏洞，而且幾乎所有 TLS 堆棧現在都為 TLS1.0 CBC 進行 1/n 拆分，從而提供深度防禦。許多伺服器根本不再允許 TLS1.0（尤其是那些受 PCI-DSS 約束的伺服器）。所以這個 A 和 Q 主要是具有歷史意義的。
實際上那個例子是錯誤的，因為它把每個都算作兩個字節，
\r而\n不是每個實際代表的單個字節。它還使用 DES 作為分組密碼，該密碼自 1990 年代後期以來已被破壞和過時。但是，如果我們忽略這些小錯誤，那麼在接下來的段落中，該文章確實正確解釋了原理（圖形簡化為我在 SX 中可以做的）：
…. 另一方面，如果他可以注入數據包，他也可以對請求進行修改。假設他這樣做了：
GET /ind | ex.jsp H | … | 會話=1 | 2345678
在這裡，我已經從被請求的頁面中刪除了一個字元到看起來完全無辜的 index.jsp，但我還將受害者塊分割成一個 8 字節的邊界。現在，如果我想找到會話 ID 的第一個數字，我最多只需要 10 次猜測：
ession=0
ession=1
注意後者是前者的結果；將 URL 縮短一個字元會導致後續塊包含已知文本
ession=（我們知道伺服器使用 cookie 名稱Session，秘密是值）加上值開頭只有一個未知字元，所以我們只需要嘗試一小部分可能的猜測塊。… 現在，有了第一個數字，我可以再次更改請求：
GET /ind | ex.js 超執行緒 | … | 會話=12 |
345678最多猜10次：ssion
=10
ssion=11
ssion=12
再次通過更改 URL，我們使一個塊包含已知文本
ession=1和單個未知字元（第二個），使其易於猜測。根據需要重複。如果
index.js甚至index.j導致伺服器錯誤並引起注意，那麼很容易選擇其他長度正確的 URL（對於 DES/3DES/IDEA 取模 8，對於 AES/Camellia 取模 16），例如query.cgi?search=able query.cgi?search=baker query.cgi?search=chubby雨披在你連結的問題中的回答說了同樣的話，除了他稱之為“機動
$$ ing $$cookie’ 到塊邊界之前的所需位置，然後 ‘remaneuver$$ ing $$’.