3

众所周知,电子邮件非常不安全。即使在客户端和发送电子邮件的服务器之间建立了 SSL 安全连接,当它在 Internet 上的节点之间跳跃时,消息本身也将是纯文本的,因此很容易被窃听。

另一个考虑因素是发件人可能不希望邮件在一段时间后或在被阅读一次后被阅读 - 即使是预期的收件人。有许多的原因; 例如,该消息可能包含可以通过传票请求的敏感信息。

一种解决方案(我相信最常见的解决方案)是将消息发送给受信任的第三方,并将该消息的链接发送给接收者,然后接收者从第三方读取此消息。或者,发送方可以向接收方发送加密消息(使用对称加密)并将密钥发送给第三方。

无论哪种方式,这种方法都存在一个根本问题:如果这个第 3 方受到损害,你所有的努力都将付诸东流。有关此类事件的真实示例,请参阅涉及Crypto AG与 NSA 勾结的崩溃

我见过的另一个解决方案是Vanish,它对消息进行加密,将密钥分成几部分并将这些部分“存储”在 DHT(即 Vuze DHT)中。通过简单地查找散列(散列与消息一起发送),可以轻松且可靠地访问这些值。8 小时后,这些值将丢失,甚至预期收件人也无法阅读邮件。拥有数百万个节点,不存在单点故障。但这也被 DHT 上的 Sybil 攻击所打破(有关更多信息,请参阅 Vanish 网页)。

那么有人对如何实现这一点有想法吗?

编辑:我想我没有说清楚。主要问题不是收件人故意保留消息(我知道这是无法控制的),而是消息在某处可用。

例如,在安然事件中,法院传唤他们索要其服务器上的所有电子邮件。如果消息被加密并且密钥永远丢失,那么加密消息而没有密钥对他们没有好处。

4

8 回答 8

1

The self-destructing part is really hard, because the user can take a screenshot and store the screenshot unencrypted on his disk, etc. So I think you have no chance to enforce that (there will always be a way, even if you link to an external page). But you can however simply ask the recipient to delete it afterwards.

The encryption is on the other hand is not a problem at all. I wouldn't rely on TLS because even when the sender and the client are using it, there might other mail relies who don't and they might store the message as plain text. So, the best way would be to simple encrypt it explicitly.

For example I am using GnuPG for (nearly) all mails I write, which is based on some asymmetric encryption methods. Here I know that only those I have given explicitly permission can read the mail, and since there are plug-ins available for nearly all popular MUAs, I'ts also quite easy for the recipient to read the mail. (So, nobody has to encrypt the mail manually and might forgot to delete the unencrypted message from the disk...). And it's also possible to revoke the keys, if someone has stolen your private key for example (which is normally encrypted anyway).

In my opinion, GnuPG (or alternatively S/MIME) should be used all the time, because that would also help to make spamming more difficult. But thats probably just one of my silly dreams ;)

于 2010-07-19T19:00:33.790 回答
1

有很多不同的方法来处理它,它们都有优点和缺点,你只需要为你的场景选择正确的一种。我认为最好的解决方法与您的“最常见”解决方案相同。受信任的第三方应该是您——您创建自己的网站,并使用您自己的身份验证。然后,您不必将假设的密钥提供给任何人。

您可以通过创建自己的客户端软件来使用双向认证方法,该软件可以读取电子邮件,用户拥有自己的证书。安全总比后悔好!

于 2010-07-19T21:07:50.567 回答
1

(免责声明:我没有阅读有关 Vanish 或 Sybil 攻击的详细信息,可能与以下内容类似)

首先:电子邮件通常很小,尤其是。与 50 mb 的 youtube 视频相比,您每天可以下载 10 次或更多。基于此,我假设存储和带宽在这里不是真正关心的问题。

就这个词的常识而言,加密会将难以理解的部分引入您的系统,因此难以验证。(想想每个人刚刚执行的典型 openssl 魔术,但 99% 的人真正理解;如果 HOWTO 中的某个步骤 X 会说“现在转到站点 X 并上传 *.cer *.pem 和 *.csr”来验证步骤1 到 X-1,我猜 10 个人中就有 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 位名称将 K 与 N 个不同(或多或少受信任的)方一起存储。

要发送消息,请将 N 个链接发送到 K's。

要销毁消息,请确保至少删除一个 K。
(*) 就安全性而言,系统将与托管 K 的最安全方一样安全。

不要采用固定的 N,不要在每条消息的单个节点上使用固定数量的 K(即在同一节点上放置一条消息的 0-10 K),以使暴力攻击变得困难,即使对于那些可以访问所有存储密钥的节点。

注意:这当然需要一些额外的软件,就像任何解决方案一样,但所需的插件/工具的复杂性是最小的。

于 2010-07-17T17:31:08.663 回答
0

如果您的环境允许,您可以使用受信任的引导环境来确保已使用受信任的引导加载程序来引导受信任的内核,这可以在发送电子邮件之前验证是否正在使用受信任的电子邮件客户端来接收电子邮件。请参阅远程证明

电子邮件客户端有责任及时删除电子邮件 - 可能仅依赖内存存储并请求无法交换到磁盘的内存。

当然,程序中可能会出现错误,但这种机制可以确保没有故意的途径来存储电子邮件。

于 2010-07-19T11:51:26.130 回答
0

IMO,这种情况最实用的解决方案是将 Pidgin IM 客户端与 Off-the-Record(无日志记录)和 pidgin-encrypt(端到端非对称加密)一起使用。聊天窗口一关闭消息就会被销毁,紧急情况下可以拔掉电脑关闭聊天窗口。

于 2012-04-11T14:59:15.107 回答
0

如果收件人知道该消息以后可能变得不可读并且他们发现该消息很有价值,他们的意图将是保留它,因此他们将尝试破坏保护。

一旦有人看到未加密的消息——这意味着以任何可感知的形式——无论是文本还是屏幕图像——他们就可以以某种方式存储它并做任何他们想做的事情。所有带有键的措施,所以一个只使处理消息不方便,但不妨碍提取文本。

其中一种方法可能是使用自毁硬件,就像在 Mission Impossible 中一样 - 硬件会显示消息然后将其销毁,但正如您所见,它也很不方便 - 收件人需要通过查看消息来理解消息只有一次,这并不总是可能的。

因此,鉴于收件人可能有兴趣破坏保护并且可以破坏保护,整个想法可能不会按预期工作,但肯定会使处理消息不那么方便。

于 2010-06-30T06:14:54.700 回答
0

如果使用 HTML 格式,您可以拥有可以在以后删除的消息参考资产。如果邮件稍后打开,用户应该会看到断开的链接。

于 2010-07-13T18:32:20.113 回答
0

正如您所描述的,这个问题听起来确实非常接近 Vanish 解决的问题,并在他们的论文中进行了详细讨论。正如您所注意到的,他们的第一个实现被发现有一个弱点,但它似乎是一个实现弱点而不是一个基本弱点,因此可能是可以修复的。

Vanish 也是众所周知的,它是一个明显的攻击目标,这意味着它的弱点很有可能被发现、公开和修复。

因此,您最好的选择可能是等待 Vanish 版本 2。使用安全软件,自行开发几乎从来都不是一个好主意,而从已建立的学术安全小组获得一些东西要安全得多。

于 2010-07-19T21:37:04.350 回答