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 = (Ya^Xb) mod P = (Yb^Xa) mod P

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

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

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

9 thoughts on “MSE/PE 的實做”

  1. 早上討論到這個問題的時候,所想到的並不是能不能把加密的資料解開,因為我也知道在目前在使用的加密演算法,都有公開規格書,但是因為計算複雜度的問題,要花非常久的時間才可解開。

    那時候所想到的是,能否透過其他的特徵「識別」出這是 MSE/PE 所傳送的資料, 例如連線的順序、連線方式,封包格式等等,不過那時沒有時間繼續看細節部分再深入研究就是了....

  2. 你可以看出來目前沒有任何一個地方是固定的 Bytes,或是以簡單的數學計算 (或是其他可以以硬體加速的地方) 就可以得知的弱點。就算有,MSE 2.0 就會出版了...

    基本上做到以 client 端 CPU resource 換取頻寬是個雙輸的事情。老人家說得對,同樣的錢拿去買硬體限制頻寬,不如增加頻寬比較實際。

  3. 加解密的方式我想一定有辦法做到讓P2P controller辨別不出來,但我們實際跟幾家vendor接觸的結果,他們都強調他們看的是traffic pattern而非封包的header,反正ISP要做的只是限頻又不是完全阻擋,倘若一些不該被限的被限,頂多也只是變慢,還不致於被客訴....

    至於拿CPU換BANDWIDTH的事,其實直接從電信成本跟設備攤提的角度來看就差很多了,很多頻寬目前的價位還是高高的(如大陸與Hinet Transit),與其買個設備分個幾年攤提,在會計帳面上還是會好看一點的....

  4. HASH 是 sha1. 所以是 20 bytes. 你的 req1, req2, req3 是什末東東。請解釋一下。

Leave a Reply

Your email address will not be published. Required fields are marked *