由于一般是根据 HTTP 协议在 Web 上传输 Atom 数据，因此要完全忽略潜在的安全隐患是不可能的。比如，联合内容会显示在多处而不是显示在其原始点（毕竟，这正是联合的意义所在），您如何证明其中一方未曾修改过数据？如果某些敏感数据只能由单一个体或组织获悉怎么办？当然，最明显的例子就是银行信息。您愿意通过原始的 HTTP feed 来接收银行信息吗？所有的敏感信息都存在这个问题，比如公司的内部信息。
这篇文章向大家介绍了如何使用数字签名和加密来解决此类问题。
还记得儿时与伙伴们分享的秘密暗号吗？您可以编制各种消息并对它们进行加密，您的伙伴可以使用暗号来解码这些消息。他还可以使用暗号创建您能够读懂的消息。这就是共享密钥（shared key）加密的一个例子，因为你们俩都有相同的暗号。
如今，这种方法能很好地防止消息内容被别人窥窃，稍后我将向大家介绍如何使用共享密钥加密来实现这一目的。
但是，共享密钥加密存在一个小问题。如果您接收到的一个加密消息告诉你使用雪球攻击女子俱乐部的房子，您如何才能分辨该消息确实是来自您的伙伴，而不是附近不怀好意的人在捉弄您呢？还有，如果您向伙伴发送了一条消息，如何才能保证只有他能够阅读该消息？
在成年人的世界里，可以通过使用公钥 — 私钥 加密来解决此类问题。它使用的并不是一个密钥，而是一个密钥对（key pair）。也就是说，一个人加密的消息只能由另一个人解密，反之亦然。
其中一个密钥是私有的，而另一个则是公有的，与其所有者相关。我们回到小孩的例子中，您的伙伴可以使用他的私钥来加密进攻计划。如果他的公钥可以成功地解密该计划，则您就能知道计划是由他发送的。当然，由于他的公钥是公有的，因此任何人都可以阅读该消息。另一方面，他可以使用您的公钥来加密消息，这就意味着只能使用您的私钥来阅读该消息。这种方法解决了安全问题，但是不能解决验证问题。
真实世界中需要结合两种技术来解决此类问题。比方说，可以对消息进行数字签名。这一过程能使您确定消息的发送者以及消息在传递途中是否被修改过。把这种技术与直接加密技术结合使用，所有的问题就迎刃而解了。
我们先从加密 Atom 条目开始。
