这个问题的目的是我只是想更好地理解 P2P 和网络以及安全/加密的性质。我是一名前端 Web 开发人员，如果我们低于 HTTP 请求，我对网络堆栈的了解并不是很好。
话虽如此，我试图了解 ISP 如何“嗅探”洪流流量以及识别的内容。我觉得这个问题会暴露我的无知，但是不可能有某种不那么可读的类似 HTTPS 的 P2P 协议吗？
我知道给定的数据包必须沿途识别其到网络的目的地，但不能将 torrent 数据包配置为仅显示其目的地，以便在到达目的地之前没有人可以识别其目的？为什么 ISP 可以只查看 P2P 流量并了解它的一切，而 SSH 却非常安全，这显然是一种无法纠正的情况？
这里的每个答案似乎对问题都有不同的解释，或者更确切地说，加密的不同假设目的。由于您将其与 https 进行比较，因此似乎一个合理的假设是您正在寻找身份验证和机密性。我将列举一些降低“安全”级别的尝试。这是一个以 bittorrent 为中心的答案，因为您用 bittorrent 标记了这个问题。
从最强大的系统开始，可以通过 SSL 运行 bittorrent（许多客户端不支持它，但在完全受控的部署中可以做到）。这给了你：
跟踪器可以对连接到它的每个对等点进行身份验证，但即使对等点列表（或一个对等点）被泄露或猜测，仍然存在对等身份验证，阻止任何未经授权的访问。
在 BitTorrent（在uTorrent客户端中），我们在磁盘层添加了对 torrent 对称加密的支持：
bittorrent 引擎中的所有内容都将在加密块上运行。数据完整性检查（碎片的 sha-1 散列）将在加密块上完成，.torrent 文件将具有加密数据的散列。像这样的加密 torrent 向后兼容不支持该功能的客户端，但他们将无法访问数据（只需帮助 swarm 并为其播种）。
要以未加密的形式下载 torrent，您可以将 &key= 参数添加到磁力链接，uTorrent 会在磁盘边界对数据进行解密和加密（使磁盘上的数据保持清晰）。任何人在没有密钥的情况下添加磁力链接，只会获得加密数据。
还涉及一些其他细节，例如加密 .torrent 文件中的一些元数据。比如文件列表等。
这不会让您选择哪些对等方可以加入。您可以向所需的对等方授予访问权限，但由于它是对称密钥，因此任何有权访问的人都可以邀请其他任何人，或发布密钥。与您找到磁力链接时相比，它不会为您提供任何更强的身份验证。
它使您在受信任的对等方之间保持机密性，并让不受信任的对等方帮助播种。
bittorrent 协议加密可能更好地描述为混淆。它的主要目的不是验证或控制对 swarm 的访问（它从 info-hash 中派生加密密钥，所以如果你能保守秘密，你就可以获得该属性）。主要目的是避免微不足道的被动窥探和流量整形。我的理解是，如今避免被识别为 bittorrent 流量的效果较差。它还对复杂的主动攻击提供了较弱的保护。例如，如果启用了 DHT，或者跟踪器连接未加密，则很容易了解信息哈希，这是关键。
在私人种子（禁用 DHT 和对等交换）的情况下，假设跟踪器运行 HTTPS，则其中没有任何明显的漏洞。但是，我的经验是，https 跟踪器拥有自签名证书并且客户端不验证跟踪器的情况并不少见。这意味着毒化跟踪器的 DNS 条目可能足以进入 swarm。
Torrent 流量可以加密，并且有 VPN/SOCKS 代理可用于重定向流量，即在连接到对等点之前通过加密隧道通过另一个国家/地区。也就是说，即使您使用此类服务，也有很多方法可以通过侧通道泄漏流量（例如，DNS 查找、不安全的跟踪器、受感染的节点），而且大多数人都没有足够的知识来遵循所有适当的安全性/匿名性预防措施。此外，将自己限制为仅与也强制加密的客户端进行通信将限制您可以连接的对等点的数量。
您正在考虑的问题是点对点加密之间的区别，在私有上下文中只有两个对等点，而在公共上下文中对等点的数量是无限的。
任何公共对等方的解密只有在某处有一个引物——一个可供所有公共对等方使用的解密密钥时才能生效。在保护 ISP 的情况下，他们也可以访问该密钥，除非有一些排他性协议仅在其他人之间共享密钥。这样做是不切实际的。
在点对点连接中，TLS 密钥协商最终会创建一个由双方共享的会话加密密钥。密钥是伪随机和特定于会话的。以这种方式在 Internet 上共享的数据对于未参与密钥协商的客户端将无法使用。