正如大多数人所知，电子邮件非常不安全。即使客户端和发送电子邮件的服务器之间有 SSL 安全连接，消息本身在 Internet 上的节点间跳跃时也将采用明文形式，从而容易被窃听。
另一个考虑因素是，发件人可能不希望邮件在一段时间后或在被阅读一次后可读，即使是预期的收件人。有许多的原因;例如，该消息可能包含可通过传票请求的敏感信息。
一种解决方案（我认为是最常见的解决方案）是将消息发送给受信任的第三方，并将该消息的链接发送给收件人，然后收件人从第三方读取该消息。或者，发送者可以向接收者发送加密消息（使用对称加密），并将密钥发送给第 3 方。
无论哪种方式，这种方法都存在一个根本问题：如果第三方受到损害，您的所有努力都将变得毫无用处。有关此类事件的真实示例，请参阅涉及的崩溃加密股份公司与国家安全局勾结
我见过的另一个解决方案是Vanish，它对消息进行加密，将密钥分割成多个片段并将这些片段“存储”在 DHT（即 Vuze DHT）中。通过简单地查找哈希值（哈希值与消息一起发送），可以轻松且某种程度上可靠地访问这些值。 8 小时后，这些值就会丢失，甚至预期的收件人也无法阅读该邮件。拥有数百万个节点，不存在单点故障。但这也通过对 DHT 发起 Sybil 攻击而被打破（有关更多信息，请参阅 Vanish 网页）。
那么有人对如何实现这一目标有想法吗？
EDIT:我想我没说清楚。主要关心的不是收件人故意保留消息（我知道这是无法控制的），而是消息在某处可用。
例如，在安然事件中，法院传唤他们索取其服务器上的所有电子邮件。如果消息被加密并且密钥永远丢失，那么拥有加密消息而没有密钥对他们没有任何好处。
（免责声明：我没有阅读有关 Vanish 或 Sybil 攻击的详细信息，这可能与下面的内容类似）
首先：电子邮件通常很小，尤其是。与 50 MB 的 YouTube 视频相比，您每天可以下载 10 次或更多。基于此，我假设存储和带宽不是这里真正关心的问题。
从常识来看，加密会在系统中引入一些难以理解的部分，因此也难以验证。 （想想每个人都会执行的典型 openssl 魔法，但 99% 的人真正理解；如果 HOWTO 上的某个步骤 X 会说“现在转到站点 X 并上传 *.cer *.pem 和 *.csr”来验证步骤1 到 X-1，我猜十分之一的人会这样做）
结合这两个观察结果，我对安全（*）且易于理解的系统的建议：
假设您有一条 10 kb 的消息 M。取 N 乘 10 kb 的内容/dev/(u)random，可能来自基于硬件的随机源，将其称为 K(0) 到 K(N-1)。使用简单的异或运算来计算
K(N) = M^K(0)^K(1)^...^K(N-1)
现在，根据定义
M = K(0)^K(1)^...^K(N)
即要理解该消息，您需要全 K。使用您喜欢的任何协议，在随机 256 位名称下存储与 N 个不同（或多或少受信任）方的 K。
要发送消息，请将 N 个链接发送到 K 个链接。
要销毁一条消息，请确保至少删除一个 K。
(*) 关于安全性，系统将与托管 K 的最安全方一样安全。
不要采用固定的 N，不要在每条消息的单个节点上使用固定数量的 K（即将一条消息的 0-10 K 放在同一节点上）以使暴力攻击变得困难，即使对于那些可以访问所有存储密钥的节点。
注意：这当然需要一些额外的软件，就像任何解决方案一样，但所需的插件/工具的复杂性是最小的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
