Gea-Suan Lin's BLOG

Monday, February 20, 2006

MSE/PE 的實做

看到 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:這是密碼學上的 ,目前 768 bits 的強度已經足夠應付藍星的 P-Cube 或是其他類似的設備。

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

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