協定加密（Protocol encryption，PE）、訊息流加密（message stream encryption，MSE）或協定頭加密（protocol header encrypt，PHE）是部分點對點網路檔案分享客戶端的特性，包括BitTorrent客戶端。它們嘗試增強隱私和保密性，並嘗試使第三方（如網際網路服務供應商）更難識別流量頭部。MSE/PE在BitComet、BitTornado、Deluge、Flashget、KTorrent、Mainline、µTorrent、qBittorrent、rTorrent、Transmission、Tixati和Vuze等軟體中有被實現。PHE在舊版本的BitComet中被實現。類似的協定混淆在最新版本的非BitTorrent系統（包括eMule）中也有實現。
基本介紹
- 中文名：BitTorrent協定加密
- 外文名：BitTorrent Protocol encryption
目的,歷史,早期方法,MSE-PE的開發,BitTorrent客戶端各版本中的MSE-PE,操作,安全性,效果,評價,
目的
截至2005年1月，BitTorrent流量占據了住宅網際網路總流量的三分之一以上，雖然這在2009年下降到不足20%。一些網際網路服務提供商通過增加其容量來處理這種流量，另有一些服務商使用專用的系統來降速對等流量以降低成本。混淆和加密會使流量更難以被檢測和控制。這些系統的最初設計目的是匿名性或保密性，但在某些國家（或地區、運營商）因網際網路服務供應商限制BitTorrent流量或用戶而變成必需品，他們認為BitTorrent流量占用過多網路資源（增加運營成本）、干擾網路正常運行，或認為或限制“非法的”檔案共享。
歷史
早期方法
協定頭加密（PHE）由RnySmile構想並最先在2005年9月8日的BitComet 0.60中實現。一些軟體如IPP2P聲稱可以檢測到使用了PHP的BitComet流量。PHE是可以被檢測的，因為只有部分流被加密。由於沒有此協定的開放規範，其他客戶端支持它的方法是通過逆向工程。
MSE-PE的開發
2006年1月下旬，Vuze（當時稱為Azureus）的開發者決定設計並實現一個新的、開放的協定混淆方法，它被稱訊息流加密（message stream encryption，簡稱MSE）。該協定被包含在2006年1月19日的Azureus CVS快照2307-B29中。
這份首稿受到了嚴重的批評，因為它缺乏幾個關鍵特徵。在幾名BitTorrent開發者磋商後，一份新的提案在幾天內被撰寫並實現到Azureus和µTorrent beta。在µTorrent中，新的協定被稱為協定加密（protocol encryption，簡稱PE）。
BitTorrent客戶端各版本中的MSE-PE
- BitComet 0.63版本，發布於2006年3月7日。它移除了舊的協定頭加密並實現了新的MSE/PE以兼容Azureus和µTorrent。
- BitTornado從T-0.3.18版本開始支持MSE/PE。截至2007年1月5日，該版本仍在下載頁面上標為“實驗性”。
- BitTorrent （Mainline）從2006年5月2日的4.9.2-beta開始支持MSE/PE。
- Deluge從Deluge-0.5.1開始支持MSE/PE。
- KTorrent在2006年4月29日的SVN版本535386中實現MSE/PE。
- rTorrent從rTorrent-0.7.0開始支持MSE/PE。
- Transmission從Transmission-0.90開始支持MSE/PE。
- Vuze（以前名為Azureus）自2006年1月25日（CVS快照2307-B33）起支持最終版標準。Azureus 2.4.0.0於2006年2月10日發布，是首個支持MSE/PE的穩定版本客戶端。不過，Azureus的實現中存在瑕疵，會導致不正確的加密片段，從而散列檢查失敗。該瑕疵在2.4.0.2版本中被糾正。
- µTorrent在Azureus的beta 1.4.1 build 407發布4年後支持MSE/PE。µTorrent的1.5（build 436）版本於2006年3月7日發布；它是首個支持PE的µTorrent穩定版本。
操作
BitComet 0.60至0.62版本中使用的PHE方法即沒有發布，也不兼容MSE/PE。
MSE/PE使用密鑰交換結合torrent的infohash創建一個RC4加密密鑰。密鑰交換有助於最小化被動監聽器的風險，而infohash有助於避免中間人攻擊。選擇RC4是為了速度更快。輸出的第一個kibibyte（1024位元組）被丟棄以防止Fluhrer, Mantin and Shamir attack。
該規範允許用戶選擇僅加密報頭或者完全加密整個連線。加密整個連線提供更強的混淆能力，但也消耗更多的CPU時間。
為確保與不支持此規範的其他客戶端的兼容性，用戶還可選擇是否仍允許未加密的傳入或傳出連線。
支持的客戶端通過節點交換（PEX）和分散式散列表（DHT）通告它們已啟用MSE/PE。
安全性
該加密方法若對應常用的對稱加密算法，加密強度約為60-80比特。在密碼學領域，這個有效的密鑰長度相當低，但該協定不是為安全傳輸而設計，而是作為一種快速並有效的混淆方法。AES曾被提出作為加密方法，但未被採用，因為會消耗太多的CPU時間。它需要迪菲-赫爾曼密鑰交換（Diffie Hellman）密鑰來做到AES級別的安全性，而AES要做到會更大，或者需要橢圓曲線密碼學，使握手要使用較多的CPU時間。
效果
一些網際網路服務提供商正在使用更複雜的措施（例如模式/時量分析，或者基於信道側數據對連線埠進行分類）來檢測BitTorrent流量。這意味著加密的BitTorrent流量也可以被限流。但是，也有些服務商繼續使用簡單、便宜的方法來識別和限流BitTorrent，因此當前的方案仍有效果。
對BitTorrent協定加密（也稱MSE）的分析顯示，數據包大小的測量統計和TCP會話中前100個數據包的數據包方向可以被用來識別混淆的協定，具有超過96%的準確性。
Sandvine應用程式採用另一種途徑，通過使播種（Seeding）失效來瓦解BitTorrent流量。Sandvine截取對等端到跟蹤伺服器（tracker）的通信並基於跟蹤伺服器返回的節點列表中的節點地址和連線埠號來識別對等端。當Sandvine在之後看到已截取的對等端列表中的對等端的連線時，它可能（根據策略）傳送偽造的TCP重置來中斷這些連線。有多種方案來抗擊Sandvine的攻擊，包括對等端到跟蹤伺服器及對等端到對等端之間的通信加密，使用微軟的Teredo使TCP連線隧道化為UDP數據包，在終端主機的TCP層中過濾掉TCP重置包，或者完全從基於TCP的傳輸變為基於UDP的傳輸等。每個解決方案都各有利弊。過濾掉TCP重置通常需要核心訪問許可權和遠程節點的參與，因為Sandvine會將重置數據包同時發給本地和遠程節點
評價
BitTorrent的發明者布萊姆·科亨（Bram Cohen）反對將加密加入BitTorrent協定，他擔心加密可能導致客戶端之間的不兼容，並還強調大多數ISP不封阻torrent協定。2006年他寫道：“我相當懷疑有些開發者受到了他的ISP的限制，並更有興趣破解他的ISP的限制，而不是整個網際網路的性能。”許多BitTorrent社區的用戶強烈反對Cohen的指責。Cohen後來也添加了加密連線到他的Mainline客戶端使其有接收能力，但不會如此傳送加密連線
