※ 引述《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