Comments on: MSE/PE 的實做

By: Gea-Suan Lin

Gea-Suan Lin — Fri, 26 Sep 2008 09:25:36 +0000

因為 req1 就是 ‘req1′ 這四個字，keyA 如果你看不懂，代表預備知識還不夠。

ttt — Thu, 25 Sep 2008 19:33:53 +0000

http://azureus.aelitis.com/wiki/index.php/Message_Stream_Encryption
確實沒有提到 HASH(‘req1′, S) 中的 req1、keyA 是什麽東西

Gea-Suan Lin — Mon, 20 Mar 2006 01:27:19 +0000

如果你不想看 spec 不要浪費時間找人問。’req1′ 就是 4bytes 的字串，其餘類推。

np — Mon, 20 Mar 2006 01:25:14 +0000

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

-TMA-1- » Blog Archive » links for 2006-02-21 — Fri, 24 Feb 2006 09:30:53 +0000

[...] MSE/PE 的實做 (tags: Tech P2P BitTorrent Cryptography Encryption PHE MSE) [...]

一個在ISP工作的路人 — Tue, 21 Feb 2006 04:18:35 +0000

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

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

gslin — Mon, 20 Feb 2006 19:05:59 +0000

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

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

GongDa’s Blog » 有關 MSE/PE 的一些想法 — Mon, 20 Feb 2006 11:27:02 +0000

[...] 感謝 Gea-Suan Lin 文章中提到的看法看完文章後，發現自己又更了解 MSE/PE 了。 [...]

GongDa — Mon, 20 Feb 2006 10:08:00 +0000

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

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