这是布赖恩斯佩克特；我是CertiVox的首席执行官。

感谢您在我们的安全信息交换服务PrivateSky上开始讨论。我会尽我所能回答关于这个线程的聪明的评论和批评。

其次，我将尽力让读者逐步了解我们的集成密钥管理和双因素身份验证的工作原理。

我邀请此线程上尚未阅读白皮书的人请这样做。我所写的所有内容都已经详细写过，并且可以在我们网站上的该文档中公开获得。但是由于没有人阅读白皮书……

首先，驳斥我们“撒谎”的说法。我们不是，事实上，我们正在努力让我们如何做我们所做的事情尽可能透明。很难与这种笼统的说法争论，所以与其去那里（“琼斯先生，你什么时候停止殴打你的妻子？”），让我们来看看这个线程上的智能点，因为有很多很少。

为此，这也是我们开源MIRACL SDK的原因，可从我们的网站免费获得。MIRACL 为 PrivateSky 提供支持，PrivateSky 中使用的相同加密过程可作为 MIRACL SDK 中的库使用，因此您可以查看代码。MIRACL 已被全球数百家公司使用，并因其针对受限环境优化的非常快速的椭圆曲线加密而享有相当不错的声誉。它受到许多组织的信任。我们非常重视这种信任；这是我们的面包和黄油。

在这里更正卢卡斯的陈述：

可能简单的答案是：不是。

如果我没看错，他们似乎只是使用了一种对称加密形式来向系统验证自己的身份，之后您可以访问您的私钥来加密数据（私钥是用您的 pin 加密的）。

这是不正确的。让我们先清理一下。您看到的使用您的电子邮件地址和 4 位密码将您登录到 PrivateSky 的 SkyPin 是一个椭圆曲线认证的密钥协议协议，它使用两个认证因素，基于IEEE P1636.3 草案标准，Wang 的协议，并添加了我们的首席密码学家，Michael Scott 博士 使用椭圆曲线双线性配对使用简单令牌和 4 位密码进行远程登录的协议。

请注意，Mike 的协议自 2002 年首次发布以来已经过广泛的同行评审，经受了十多年的密码分析，我们已经发布了更新版本，这次适用于 Wang 的协议。

在这两个因素中，第一个因素是存储在您的浏览器中的数学令牌，锁定在我们的身份验证服务的域中，第二个因素是您的密码。它的工作原理是这样的：您使用的 SkyPin Pad 实际上是对在您的电子邮件地址 ID 中发布的基于身份的加密密钥进行重构，我们会在您注册时向您发布。在注册过程中，SkyPin Pad 使用您选择的 4 位数字对您颁发的 IBE 密钥执行一个方程式。此过程在本地执行。我们不知道那 4 位数字是什么。到那时，它就变成了我们所说的“令牌”。令牌存储在浏览器的 HTML5 本地存储中，而不是会话存储中（即，不是 cookie）。这已锁定到我们的身份验证服务的域。

下次登录时，SkyPin Pad 由我们的网络服务器（通过 TLS，由 DNSSEC 保护的域）提供服务，并在您的浏览器中本地运行。SkyPin Pad 将您的 4 位数字作为输入，反转等式，重新构建您在注册时发布的基于身份的加密密钥，再次在本地执行。这是斯科特的协议。下一步是基于 Wang 协议的经过身份验证的密钥协商协议，其中加密的 nonce 与服务器的 ID 和尝试相互验证的个人的 ID 进行交换。在协议结束时，服务器和个人都已相互识别，并且每一方都有一个 AES 128 位密钥，即会话密钥，可供他们使用。因此这个词；认证的密钥协商协议。

所以不，这个系统不使用对称密钥来验证用户。它是一个基于椭圆曲线密码学的双因素身份验证系统，在 JavaScript 中运行，专为兼容 HTML5 的浏览器量身定制，可执行经过身份验证的密钥协商。

卢卡斯的这个陈述也是不正确的（注意卢卡斯，通常你不会用公钥解密，你用公钥验证签名，你用公钥加密）：

它仍然可以用其他人的公钥浏览器解密。但是话又说回来，每个人都有一个可用的公钥，他们只需要从服务器获取它并通过浏览器应用它。– 卢卡斯考夫曼 5 小时前

并且通过关联 Rasmus 对这个声明是正确的（感谢您阅读白皮书，顺便说一句）：

根据白皮书，他们使用 SK-KEM，这是一种基于身份的加密方案。这解释了为什么您不需要 B 的公钥来向他发送加密消息（电子邮件地址是公钥）。

在像我们使用的 SK-KEM 的变体这样的指数反转系统中，它实际上是一个密钥封装系统，其中内容加密密钥使用带有系统全局公钥输入的协议进行封装（即加密），并且收件人的电子邮件地址。该消息使用ECCSI协议使用我们的私钥生成器发出的用户私钥进行签名。用户使用从我们的私钥生成器发出的不同私钥来解密消息，使用SAKKE协议（SK-KEM 的一种变体）。SAKKE 最酷的地方在于它还具有联合私钥生成器的能力。假设用户可以访问另一个人的私钥生成器的公共参数，拥有 PKG A 的私钥的用户 A 可以与拥有从 PKG B 发布的私钥的用户 B 进行通信。

ECCSI 和 SAKKE 都是名为MIKEY-SAKKE的 IETF 信息草案的一部分，该草案正在标准化以通过 3G 网络提供语音数据和加密。MIKEY-SAKKE 对 PKG 的操作有严格的指导方针，以涵盖诸如主密钥轮换（每 30 天）和数据包组装等细微差别。

直到最近，还假设您无法在指数反转系统中分发私钥生成器。值得庆幸的是，Smart 和其他人设计了一种多方计算协议，实现了这种可能性。在这项工作的进一步发展中，Smart 和 Geisler 发表了一篇名为“ Distributing the Key Distribution Center in Sakai–Kasahara Based Systems”的论文。”

实际上，您可以将 PKG 拆分为分布式私钥生成器或 D-PKG。这样做的好处是，在初始设置之后，万能钥匙完全不在任何地方。它被分成三份。三个节点中只有两个节点需要可用于将私钥共享给目标方。主节点在设置后下线并丢弃。假设您已经构建了执行此操作的流程，则可以根据请求动态创建此类系统中的私钥共享。

拉斯穆斯发表了这样的声明：

通常基于身份的加密依赖于受信任的第三方。因此，他们声称自己无法解密消息是基于他们将主私钥和相关的私钥生成器放置在基本上相当于硬件安全模块的内部。

卢卡斯发表了这样的声明：

是的，他们似乎只是把信任放在了其他地方。他们自己无法解密，但他们声称没有其他人可以解密的说法似乎是错误的

拉斯穆斯是部分正确的，卢卡斯是不正确的。它实际上是几个硬件安全模块，它们都没有真正拥有完整的万能钥匙。我们采取了额外的步骤：将 D-PKG 节点放入具有防篡改、防篡改、在启动 VM 时进行完整性验证的 HSM，并且不携带任何状态（除了它们共享的主密钥和分配共享的代码）认证请求）。如果不破坏一些昂贵的工具包，我们就无法访问 D-PKG 的份额。但是让我们假设我们可以重组 PKG 的份额。

因为我们遵循 MIKEY-SAKKE 操作指南，这些 D-PKG 只运行一个月，也就是说，主密钥和后续发布的私钥只有一个月有效，并且整个人口每个月轮换一次。

在 PrivateSky 中，将要求用户创建一个唯一的密码。这用于创建一个 32 字节的长寿命ECDH私钥（以及后续的公钥），它也可以在ECIES设置中使用。用户的 ECDH 公钥存储在我们的目录中。D-PKG 的 ECDH 密钥对不是长期存在的，只有每月一次。发行新密钥时，会在 D-PKG 月私钥和用户 ECDH 公钥之间创建一个 DH 密钥，为用户新发行的 ECCSI 和 SAKKE 私钥加密。这发生在每个用户身上。这些存储在我们的用户目录中，因此他们可以在 30 天主密钥轮换窗口之外解密旧消息。

关键是，在使用主密钥份额的 30 天窗口之后，VM 被销毁，HSM 内的密钥材料被擦除，我们重新开始。

所以让我们概述一下一般的攻击场景：

在 30 天窗口内，为了让我们解密数据（或在我们收到信息请求传票时交出密钥）：

• 我们需要小心地破解 FIPS 140-2 3 级的 HSM，以免破坏单元两次。在两个不同的数据中心。

在 30 天窗口之外：

• 我们需要破解 AES 256 才能解密存档的私钥或
• 必须有人为每条消息破解 AES 128 位

您可能想知道，为什么这些家伙会不遗余力地构建这样一个系统？尤其是鉴于这种承认：

用户 1202236 发表以下声明：

感谢您的澄清。因此，现在您不再信任软件公司，而是信任硬件公司，并且该软件公司实际上使用了提供的硬件。在我看来，与 PGP 相比，您需要信任很多人。

这是正确的。让我问这是一种更直接的方法：在信任范围内，如果您想 100% 确定没有人可以看到您的数据，使用 PGP 或 PrivateSky 更好吗？答：毫无疑问，通过 PGP 等系统创建自己的私钥作为信任模型更好。完全没有问题。

只有一个问题。 PGP 和当前最先进的技术对于普通大众来说太难使用了。这个董事会的人不会介意你。但我的意思是我的女儿，或者她的朋友，或者我的父母。

在 PrivateSky 中，使用 PIN 码、密码和您的电子邮件地址，我们可以让您靠近，并提供双重身份验证作为奖励。而且你不需要学习任何东西。使用 PrivateSky 与周围的任何其他网络资产相比，您不必做任何不同的事情。这就是我们建造它的原因。

CertiVox 的人真诚地认为，仅仅因为我们想通过互联网交流某些东西，并不会给政府、NSA、Dropbox、谷歌或任何媒体公司使用我家人信息或我的信息的权利，以参与有史以来最大的数据挖掘骗局对人类犯下的罪行。

从业务角度来看，我们的架构还完成了以下任务： 我们将收到来自当局的信息请求。当您经营一家 Saas 业务时，这是不争的事实。值得庆幸的是，在英国和欧盟，对此有正当的程序和法律。我们如何合规以及我们证明合规程度的能力取决于我们开发的架构。如果我们可以清楚地访问您的数据，那么我们必须将其交出。如果不是，那我们还得把它翻过来。但是，如果我们上交的东西是加密的，而我们不拥有密钥，那么数据（它是加密的）有什么用，为我们提供 FISMA 搜查令或欧盟等价物有什么用？对于一家年轻的公司来说，满足信息要求真的非常昂贵。不成为此类请求的目标是一种竞争优势。

这让我想到了下一点。CertiVox 的团队打赌，安全信息交换服务存在市场，我们的业务模式依赖于不查看您的数据。我们相信（也许天真地）有足够多的人和组织担心隐私受到侵蚀，但没有技术专长来做任何事情。Dropbox 需要查看您的数据以进行重复数据删除。Google 需要查看您的数据才能为您投放广告。我们也不做，也永远不会做。

为此，我们将很快推出让任何人都可以运行您的 OWN 分布式私钥生成器的功能，并在我们的系统上注册这些生成器（通过 SAKKE 联合功能），完全让我们脱离循环。您可以控制自己的用户群，可以随意轮换主密钥，撤销用户等。这将为您提供与 PGP 等效的信任模型。

最后，让我们来看看我们的集成密钥管理系统是如何工作的。我们称之为隐身键。您可以下载信息图形 PDF，它是以下说明的可视化图表：

要加密和签署消息：

1. Alice 使用她的 SkyPin 和电子邮件地址登录 PrivateSky。双因素认证密钥协商协议生成一个 AES 128 位密钥，供浏览器端和认证服务器端使用。
2. 身份验证服务器将 AES 密钥传递给我们的“黑匣子”，即 D-PKG 节点。
3. D-PKG 节点组装 Alice 的 ECCSI 密钥的份额，并使用 AES 密钥对其进行加密。
4. Alice 收到加密的 ECCSI 密钥（共享），用她的 AES 密钥解密共享，从共享中组装 ECCSI 密钥，然后准备开始。
5. Alice 给 Bob 写了一条消息，并用一个 AES 密钥加密消息，称为内容加密密钥。
6. Alice 使用全局公钥和 Bob 的电子邮件地址的输入来封装内容加密密钥，并将加密/封装的密钥附加到消息中。
7. Alice 使用她的 ECCSI 密钥对消息进行签名。

要解密和验证消息：

1. Bob 使用他的 SkyPin 和电子邮件地址登录 PrivateSky。双因素认证密钥协商协议生成一个 AES 128 位密钥，供浏览器端和认证服务器端使用。
2. 身份验证服务器将 AES 密钥传递给我们的“黑匣子”，即 D-PKG 节点。
3. D-PKG 节点组装 Bob 的 SAKKE 私钥的份额，并使用 AES 密钥对其进行加密。
4. Bob 收到加密的 SAKKE 私钥（共享），用他的 AES 会话密钥解密共享，组装 SAKKE 私钥，然后准备开始。
5. Bob 在他的门户中收到消息，其中包含封装的内容加密密钥。
6. Bob 验证 Alice 的签名，并用他的 SAKKE 私钥对内容加密密钥进行解封装。
7. Bob 使用内容加密密钥来解密消息。

所以你有它。你可以与数学、实现或我们的意图争论，但希望我们已经把这三个都说清楚了。

感谢您一直阅读，请注册 PrivateSky！您可以亲眼看到所有这些都在发挥作用。

布赖恩

根据白皮书，他们使用SK-KEM，这是一种基于身份的加密方案。这解释了为什么您不需要 B 的公钥来向他发送加密消息（电子邮件地址是公钥）。

通常基于身份的加密依赖于受信任的第三方。因此，他们声称自己无法解密消息是基于他们将主私钥和相关的私钥生成器放置在基本上相当于硬件安全模块的内部。

逐点回答布赖恩坎贝尔的问题/陈述：

如果您的用户是调查的目标，政府可能会禁止您对您的 D-PKG 实例进行 30 天轮换，并要求您将其交出以进行取证分析。

这可能会发生，但在欧盟和英国极不可能发生。在其他住所不太可能。此外，如前所述，因为它们是 HSM 中的即发即忘代码块，并且因为它们不携带任何状态，甚至不携带整个主密钥，并且因为 HSM 已通过 FIPS 140-2 3 级验证，所以它将是一个很难破解的坚果。此外，阻止我们进行轮换可能会违反英国的计算机滥用行为，因此如果确实发生了，至少它会成为一个很好的法律剧场。

资源充足的政府可能能够绕过 HSM 并恢复私钥。你有什么措施可以防止这种情况发生吗？

你能提供更多细节吗？我们团队中的许多人，包括我自己在内，都曾为商业 HSM 供应商广泛工作过。我们不知道如何以任何技术方式使用适当制造的 HSM 达到 3 级水平。如果您详细了解，请务必说出来。

当私钥被托管并使用仅可能由您创建的 AES-256 位密钥进行保护时，我们将依靠 AES 256 位来完成其工作。如果这被破解了，那么我们都有比 PrivateSky 更大的问题要担心。

此外，解密在 JavaScript 中运行客户端。有什么保护措施可以防止恶意 JavaScript 被注入（由您、由 XSS 攻击或由获得根证书和 MITM 的人注入您的网站）并窃取用户的私钥？

首先，我们在协议中不使用任何证书，这称为无证书加密. （请注意，我们没有使用 wiki 文章中描述的相同系统，但我们相信我们能够抵抗类型 1 和 2 的对手）。我们确实使用服务器端 TLS 证书来防止安全门户上的 MITM，并使用 DNSSEC 保护我们的域，以防止缓存中毒。但是前台身份验证解决方案 SkyPin 实际上可以在没有 TLS 的情况下运行（如果我们选择这样做的话），但它不能没有 DNSSEC。DNSSEC 是更为关键的组件，因为经过身份验证的密钥协商协议与建立 Diffie-Hellman 密钥协商会话时每天以明文形式交易大质数（SSL / TLS）的协议相同。这是可以建立 SSL/TLS 会话的公认方式之一。听起来很神奇；你在服务器和客户端之间来回交易大质数，甚至中间的人在协议结束时也不知道会话密钥。这就是 SkyPin 正在做的事情（在非常高的水平上）。

因此，通过 SSL/TLS 保护的身份验证过程，更重要的是 DNSSEC，我们觉得您所描述的内容虽然可能，但确实是远程的。在您提到的事情中，这是用户最有可能受到威胁的方式：

• 恶意 javascript/xss 攻击

如果您安装了恶意浏览器插件并托管了正在录制屏幕的恶意软件，我们可以很容易地看到这种情况发生。如果浏览器插件实际上以一种可以从会话存储中窃取项目（对浏览器的灾难性攻击）而不是将它们锁定到域的方式攻击浏览器，并且您的主机计算机感染了记录您的恶意软件屏幕，那么理论上攻击者有可能从浏览器的存储中窃取您的 SkyToken，记录您的 PIN 输入（尽管我们已经采取措施来缓解这种情况），然后以某种方式，通过相同的攻击，重新插入固定到另一个浏览器并在另一台计算机上冒充您执行经过身份验证的密钥协议协议并访问您的帐户。请记住，这两件事都需要发生，在你不知情的情况下。如果您至少运行了主机防病毒软件但可能的话，这是一项艰巨的任务。他们还需要在登录过程中绕过我们的欺诈筛查。这意味着，攻击者无法将您的 PIN / 令牌从您位于皮奥里亚的机器中取出并立即开始从中国登录该服务。我们筛选地理位置等。

• 我们的 TLS 证书供应商的根证书被泄露，您浏览到另一个认为其 PrivateSky 的站点。

不幸的是，最近发生了太多这样的事件。这是我们非常担心的事情，这实际上是我们实施 SkyPin 的原因。如果我们仅使用用户名和密码将您登录到这个安全门户，而我们的域中没有 DNSSEC，我们将很容易受到谷歌去年受到革命卫队礼遇的同样攻击。

除非您看到 SkyPin 提示，否则不要登录 PrivateSky。因此，作为上述攻击的反面，要阻止这种攻击，攻击者需要破坏 DNSSEC 协议，破坏我们的 TLS 证书供应商的根证书并破坏我们的服务器，以便执行 MITM 攻击以获得访问权限您的私钥是动态生成并发送给您的。正如前面在第一个答案中所述（同样，它在白皮书中），私钥的共享本身在 D-PKG 中使用会话密钥进行加密，会话密钥仅在您的浏览器中可用，因为通过SkyPin 使用我们的身份验证服务进行身份验证的密钥协议协议。您需要对我们进行实际身份验证，通过主机上的一些恶意软件从浏览器中窃取会话密钥，这也意味着损害我们的 TLS 供应商根证书和 DNSSEC。并不是说这是不可能的，但它需要一些严肃的、严肃的国家资助的资源。

• CertiVox / PrivateSky 注入的恶意 javascript

我们其实也担心这个。我不会透露我们的内部控制流程是什么，但我们对此非常认真。请记住，尽管如前所述，我们的业务“赌注”是我们正在掷骰子，认为像我们这样的服务有市场，关键区别在于看不到您的数据。所以在这种情况下，这是一个内部 rouge 员工在搞乱代码。可能，但考虑到我们现有的保障措施，不太可能。

作为我向 Brian Campbell 提供的答案的更新，两位安全研究人员，其中一位是出色的信息安全专家 Aldo Cortesi，指出 PrivateSky 容易受到我们 SSL 证书供应商的灾难性损害。

正如阿尔多所说（阿尔多，我希望你不介意我引用你的话），

“......如果服务器是恶意的或存在 SSL 证书泄露......PrivateSky 无法抵抗攻击......”

以下是 SSL 证书攻击的工作原理（这是一个粗略的简化，但通常是正确的）：

1. 政府/国​​家赞助的实体必须首先破坏我们用来保护 SSL 会话的证书供应商（Globalsign 或 Verisign）（这不是小事，我相信在 Diginotar 攻击之后，这两个供应商的安全性都得到了升级）。
2. 政府实体/国家资助的实体将在 PrivateSky 和用户之间的网络连接上建立一个分接头，以在选择他们的攻击受害者后促进 MITM 攻击。
3. 用户登录后，用户的浏览器向 PrivateSky 发送消息请求，攻击者在响应中插入恶意的 JavaScript 行。
4. 然后，此恶意 JavaScript 可以解密消息，并通过 ajax 调用将内容发送到在查询字符串日志文件中记录消息内容的服务器。

奥尔多接着说，

“关于这件事有两点需要说。首先，这不一定是 PrivateSky 价值主张的核心。该产品能够抵抗困扰传统服务的一系列其他问题——在妥协的情况下大量用户数据泄露、披露客户信息的法律压力等等。

其次，在我看来，制作一个 100% 基于 Web 的产品来抵抗恶意服务器和 SSL 拦截目前是不切实际的，肯定需要应用程序本身“外部”的东西（比如浏览器扩展），而且成本很高用户便利的成本。当我制作 cryp.sr 时，我正试图解决这个问题，我通过在浏览器扩展中使用加密哈希检查来自服务器的数据“包”的完整性来做到这一点，有效的哈希通过一个完全独立的频道。请参阅我在这里写的（长）博客文章：

http://corte.si/posts/security/hostproof.html

http://corte.si/posts/security/crypsr.html

如果有一种仅限浏览器的方法来解决这个问题，那肯定是开创性的。不过，我相当确信没有办法做到这一点。

我想指出的其他一点是，尽管我们知道 SSL 证书信任系统已损坏，但尝试在应用程序级别抵消这一点并不是一个好主意。有安全意识的客户可以使用其他解决方案来解决此问题。一种可能性是客户端证书固定，其中用户指定证书必须使用某个公钥签名才能有效。Chrome 对此具有初期支持，通过其 STS 模块用于所有 Google 属性：

http://dev.chromium.org/sts

另一种可能性是 Convergence，这是一个由非常杰出的安全研究人员 Moxie 最近发布的替代证书验证方案：

http://convergence.io/

目前尚不清楚 Convergence 是否会起飞，但它提供了良好、强大的 SSL 拦截保护，完全独立于传统的 SSL 签名信任网络。因此，我的基本观点是，无论 Certivox 做什么，都可能不值得尝试在 HTTP 应用程序级别修复或补偿 SSL 拦截的可能性。

我们必须记住的另一件事是我们在这里讨论的攻击类型的相对概率。目前，只有极少数实体有能力创建看起来有效的恶意 SSL 证书——基本上，我们正在调查情报机构，也许还有其他一些人已经破坏了受信任的签名者。做到这一点的能力受到严格的保护，并且非常谨慎地使用。

就其本质而言，可以检测到何时使用这样的 SSL 证书进行拦截，这仅仅是因为签名身份必然会发生变化（这是 cert pinning 检测到的）。因此，当它们被使用时，它们会以非常有针对性的方式小规模使用，针对特定的个人或组织。当这个程序被偏离并且假证书被大规模地业余使用时，它们不可避免地被检测到并且极其宝贵的签名资产被毁掉（参见伊朗最近的行动，以及随之而来的 Diginotar 黑客事件的发现）。因此，与此相比，Certivox 服务器被入侵的可能性要高出一个数量级，而客户端桌面环境再次被入侵的可能性要高出许多数量级。唯一需要关注恶意证书的人是那些“特殊”客户，他们可能会成为拥有这些能力的人的目标。这些人当然应该使用我上面提到的 SSL 级别的解决方案——其他人都可以放松。”

我想这可能是提及我们将很快引入移动客户端的好时机。

正如 Aldo 继续说的，“一个 IOS 应用程序可以简单地构建证书固定，开发环境不易受到注入问题的影响，执行环境更加安全，并且不需要从 Certivox 服务器下载可执行代码。它还解决了先有鸡还是先有蛋的问题，因为应用程序与 Certivox 服务器分开分发，并使用单独的身份验证和验证过程（在本例中为 Apple 的应用商店）。像这样的 IOS 应用程序确实可以（有一些附加条件）满足 Certivox 目前提出的强烈要求——即没有人（包括 Certivox）可以读取客户端数据。”

Aldo 在最后一句话中所指的是，一位安全研究人员对我们在营销材料中使用“不能”这个词提出了巨大的质疑（我应该说这是我们遇到的唯一这样的意见) 并指责我们故意“误导”，因为我们是一个 Web 应用程序，如果我们以邪恶、恶意的方式操作系统，我们“可以”看到客户的数据。正如我们一直所说的那样，我们没有以这种方式操作，结果是我们没有以任何可能为我们提供潜在访问权限的方式存储用户的加密数据（因此我们使用“不能”这个词） .

正如我在这个帖子中所指出的，你必须相信运行 PrivateSky 的人不会在运行过程中以恶意或邪恶的方式行事，这对于某些人来说可能是不恰当的信任。PGP / SMIME 或您创建初始私钥/公钥对并且该密钥完全在您的控制之下的其他系统在这方面仍然是最佳的（但是对于普通用户来说很难理解）。

我将开始一个单独的博客/线程详细说明这种情况并征求意见、建议和反馈。董事会成员的意见对我们很重要，所以我希望你能参与对话。

最后，我很想在另一点上再次在此线程上发表一些评论：

首先，一旦引入了移动和桌面客户端，而 Web 应用程序只是一个方便的 UI，我们是否应该让客户能够在关闭这种潜在的客户端数据泄漏的上下文中关闭对 Web 应用程序的访问，因为假设您的消息和文件正在通过已安装的客户端之一交换，我们的证书供应商的灾难性妥协，而这种妥协不存在？我还应该注意，即使是 XSS 攻击（正如我在上面已经发布的那样）也可能泄露用户数据（但这将是我们的大联盟搞砸了）。这种证书泄露攻击最令人担忧的是，它完全不在 PrivateSky 的控制范围之内，无论多么遥远并且需要国家赞助的资源。

其次，在堵住这个漏洞的背景下，您最想先见到什么样的客户？
• Mac OS X • iOS • Android • Windows • Linux • Windows Phone

注意：我们的第一个客户端将是一个 Outlook 插件，将很快推出。

最后，我还应该指出，我们将很快推出让 PrivateSky 系统上的任何人都可以运行自己的指数反转分布式主密钥服务器的功能，如果对 PrivateSky 门户的访问受到限制并且消息仅被加密和在已安装的客户端上本地解密。那时你只需要相信自己。

干杯，布赖恩