→ HYL:想了想，上面寫的有點錯，水管大反而不利 128.196.132.172 12/28
→ HYL:應該改成開放的connection數夠多 128.196.132.172 12/28
推 reader:這樣就懂了 假檔問題的確是一件麻煩 61.222.173.26 12/28
※ 引述《reader (讀者)》之銘言：
: ※ 引述《reader (讀者)》之銘言：
: : 推 HYL:談到非技術的層面，BT在現實社會中比eMule 128.196.132.172 12/28
: : → HYL:安全，BT採用一個個獨立的tracker，相較於 128.196.132.172 12/28
: : → HYL:eMule，當資料的所有權人生氣時，較不容易 128.196.132.172 12/28
: : → HYL:抓到終端使用者，eMule的設計上，只要找到 128.196.132.172 12/28
: : → HYL:相對的 MD5值，一串粽子就拎起來到法院去 128.196.132.172 12/28
: : → HYL:了，BT相對上來講一次抓到的人較少 128.196.132.172 12/28
: 但技術上來說, eMule 的做法是比較對的，同樣的文件應該要有
: 同樣的 key value.
: 我就不考慮法院的問題了，若考慮太多，到時跟 Isamu Kaneko
: (winny 的作者) 一樣被告，那也麻煩。
BT是用SHA1來做 key的，BT在設計上tracker(rendezvous node)
不會互相交換資料，這點跟 eMule是比較不同的。
: : → HYL:另一點則是eMule的設計上讓BadUser能夠放 128.196.132.172 12/28
: : → HYL:出假資料，讓其它始用者無法完檔 128.196.132.172 12/28
: eMule 也可以用 file hash key 來下載，只是大家習慣用內建
: 搜尋功能罷了。
嗯... 我這邊解釋的不是很好讓你誤讀了。
目前某些軟體公司為了阻止 p2p盜板的盛行，在 eMule上使用相
同的 key值告訴大眾他有這檔案，但是當你下載並 hashing後會
發現，傳下來的資料hash值不合，於是捨棄掉這 chuck，重新傳
送一次。
當軟體公司的水管夠大、結點夠多、上線時數夠長，這類的惡意
使用者能夠把整體的傳輸效率拖下來，讓使用者陷入，下載、捨
棄重傳的迴圈。
當然時間拉的夠長，善意使用者的比率高到一定程度後，資料還
是能夠成功下載，但對於 p2p file sharing 大宗的電影來說，
一開始惡意使用者的比率高，能夠幫發行公司搶到一兩週的上映
期那就夠了。
: : → HYL:另外最近 MD5被找到collison的影響也還未 128.196.132.172 12/28
: : → HYL:知 128.196.132.172 12/28
: 這有點麻煩，我覺得的確不應該單靠 MD5. 它的安全問題一直是
: 一個問題。
: 或許可以改用 RIPEMD-160, 雖然只有 3 成的速度，但是安全性
: 相對來說高得多。
Cryptology :Q 修過門課念過本教課書，深覺這東西對我來說
是有字天書...
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 128.196.132.172