MSE/PE 的實做

看到 GongDa’s Blog 的 Bittorrent 的 Protocol header encrypt(PHE)、Message Stream Encryption(MSE)/PE 這篇提到：

另外，和 rxlin 討論的時候，他有提到說都公佈了實作部分的話，那是不是 ISP 也知道怎麼擋了…-_-|

SSL 也公佈了實做的部分，你目前有辦法截聽內容嗎？同樣的思路放到這邊來，我只要把固定字串的判斷改用密碼學裡面的方法，是不是也可以達到「無法偵測」的效果？

目前 MSE 1.0 版是透過五個步驟把資料送出去：

A->B

Diffie Hellman Ya (96 bytes)
PadA (Random, 0 ~ 512 bytes)

B->A

Diffie Hellman Yb (96 bytes)
PadB (Random, 0 ~ 512 bytes)

A->B

HASH(’req1′, S) (16 bytes)
HASH(’req2′, SKEY) xor HASH(’req3′, S) (16 bytes)
ENCRYPT(VC, crypto_provide, len(PadC), PadC, len(IA)) (Random, RC4)
ENCRYPT(IA) (Random, RC4)

B->A

ENCRYPT(VC, crypto_select, len(padD), padD)
ENCRYPT2(Payload Stream) (這邊開始傳實際的內容)

A->B

ENCRYPT2(Payload Stream) (這邊開始傳實際的內容)

前面兩個步驟是雙方先各自產生一個 Xa 及 Xb，然後各自計算出 Ya 及 Yb 丟給對方。對方收到後用自己的 Xb (或 Xa) 與 Ya (或 Yb) 運算，就會得到 S，也就是規格裡面這段：

DH secret: S

這就是 D-H exchange，如果你問，在得知 Ya 與 Yb 後，是否可以求得 S，或是更強烈，直接求得 Xa/Xb：這是密碼學上的 Discrete Logarithm Problem，目前 768 bits 的強度已經足夠應付藍星的 P-Cube 或是其他類似的設備。

接下來的 SKEY 是 .torrent 檔案裡面的資訊，第四步的 ENCRYPT 是 RC4，最後面的 ENCRYPT2 是選用 plaintext 或 RC4 編碼，但到這邊的 offset 已經不固定了…。

以這個架構，目前看不出來要怎麼擋。也許是透過軟體實做上的瑕疵 (像是亂數太過規則之類的)，不過這個就算發生，也只是那套軟體的問題。另外一種可能是透過 MSE 在大量連線上可能造成密碼系統的弱點，不過到時候 2.0 版又會跟著出爐…