作为一名 Jami（以前的 Ring）开发人员，我将尝试回答这个问题。当然，这个答案不可避免地存在偏见和不完整，但它可能会回答一些关于 Jami 工作原理的担忧或误解，并有助于理解其架构以及该架构的局限性。

构建安全的分布式实时通信平台通常需要在易用性、性能和隐私之间进行权衡。Jami 的安全模型并不完美，并且可能会不断发展，我们愿意接受评论、建议和批评。如果需要，我将尝试编辑此答案以添加更多详细信息。

看起来它们并没有为语音或聊天对话提供完美的前向安全性。...他们没有使用像 OTR 或 Axolotl 这样专为实时通信而设计的协议。...他们对加密的描述证实了我的担忧。他们没有使用像 ZRTP 这样的协议来防止 MITM 攻击。

Jami 建立一个经过身份验证的对等 TLS 1.3 会话（使用 GnuTLS），并强制执行 PFS 密码套件，通常是 (TLS1.3)-(ECDHE-SECP384R1)-(RSA-PSS-RSAE-SHA384)-(AES-256- GCM) 被使用。

此 P2P 认证 TLS 通道用于 SIP 信令，临时 SRTP 媒体加密密钥在此通道上与 SIP 协商。这意味着 Jami 上的实时通信（音频和视频）是 PFS 和端到端加密的。但是，Jami 不提供其他保证，例如拒绝。

在“经典”（基于服务器的）SIP 中，协商 SIP 中的媒体密钥是一个问题，因为 SIP 服务器可以以纯文本形式查看这些密钥，从而破坏端到端加密并允许 MITM 攻击。这就是 ZRTP 通过在 RTP（媒体）通道上执行 DH 密钥交换来解决的问题。在经过身份验证的 P2P 通道上使用 SIP 使得使用 ZRTP 变得不必要。

“Ring”使用的是 SIP 协议，该协议非常陈旧，对 P2P 不友好。

SIP 协议可以很好地用于 P2P，就像人们可以使用 HTTP 进行 P2P 通信一样，它是一种成熟且强大的电话协议，即使它并不完美，有些人更喜欢 XMPP 或其他协议。

他们声称它是一个“去中心化”的软件，这是公牛***。

Jami 是完全分布式的，比去中心化更强，通过使用 OpenDHT（类似于 Bittorrent 使用的 Kademlia 分布式哈希表）查找联系人 IP 地址，这些地址以加密ICE候选的形式存储在 DHT 上，用于建立经过身份验证的 TLS P2P 通道。用户名（名称<->公钥映射）在分布式区块链（以太坊合约）上注册。据我所知，没有其他实时通信系统能够提供这种级别的分发。

环开发人员在这里。Ring是一个分布式通信平台，它的节点是DHT网络的一部分，所以它们的IP确实是暴露的。

这是使用分布式网络的一个缺点：DHT 节点 IP 地址暴露在分布式网络上，这是一个有效的隐私问题。当前的设计不允许将 DHT 节点与 Jami 公钥以加密方式链接，我们努力使这种分离尽可能强。

他们也在修补他们的加密库——如果你必须修补你正在使用的加密库，那就大错特错了。

它不是建立在破碎的东西之上吗？即，TLS/SSL。... 这是一个复杂性的问题——处理的东西越复杂，结果就会有越多的错误。使用像 TLS/SSL 这样复杂的东西确实有助于产生错误的加密代码。IMO 任何使用 SSL/TLS 的东西迟早都会被破坏。Tox 使用 NaCl/libsodium 的原因之一。

（以上评论由 Tox 开发人员发表）

我们不会“修补我们的加密库”；当发现错误或漏洞时，更新库。

我们生活在现实世界中，没有任何加密库（也没有一般的库）是完美的。随着时间的推移，每个加密货币最终都会被破解——这不是预测，而是观察。

TLS 复杂性是一个缺点，但优点是能够协商密码套件，因此当密码套件开始被认为很弱时，可以优雅地过渡到新的密码套件，而不会破坏现有的实现。

Libsodium (NaCL) 是一个出色的高质量库，但无法直接与 TLS 相提并论。NaCL 提供基本的加密构建块，而 TLS 是一个执行整个事情的协议：身份验证、密钥交换、加密等，以一种标准且经过很好审查的方式。

在构建 Jami 时，我们尽量不重新发明轮子，以避免增加漏洞的风险。我们没有使用 libsodium 构建我们自己的协议，而是更喜欢依赖 TLS，并专注于以最佳方式使用它。

aberaud说：

Ring 建立一个经过身份验证的对等 DTLS 1.2 会话（使用 GnuTLS），并强制执行 PFS 密码套件，通常使用 TLS_ECDHE_RSA_AES_256_GCM_SHA384。

此 P2P 认证 TLS 通道用于 SIP 信令，临时 SRTP 媒体加密密钥在此通道上与 SIP 协商。这意味着 Ring 上的实时通信（音频和视频）是 PFS 和端到端加密的。但是，Ring 不提供其他保证，例如不可否认性。

根据您所说的 PFS，“环上的通信（音频和视频）是 PFS”部分是正确的。从对话到后续对话，即在两个后续连接建立（密钥交换）之间，通信确实是完美的前向安全和后向安全。但是，在交换多个消息的同一对话期间，每个后续消息都使用相同的密钥进行加密。

因此，同一会话中的消息不会以 PFS 或后向安全方式进行交换。

为了在同一对话中实现 PFS 和 BS 通信，确实应该使用 OTR、Axolotl 之类的东西，但这并不是直接最适合音频/视频，而是更适合文本消息。如果我们将问题限制为音频/视频加密，可能是 SCIMP（来自 Axolotl 的棘轮之一）可用于在同一对话期间进行通信 PFS（但不是 BS）。关于组中的消息交换，Ring 应该使用类似GOTR，mpOTR甚至在每个人之间都有一对一安全通道的 Axolotl。虽然，Axolotl 本身并不管理任何群体问题，并且 GOTR 的设计旨在超越 mpOTR。因此，GOTR 可能是最适合的。值得一提的是，Ring 开发团队实际上从年初就开始研究这些情况。

这是 ring.cx 不是特别安全的更多原因（实际上它几乎不能正常运行）。

安全性在很大程度上与攻击向量有关，并减少进入系统的数量。您永远不会将其减少到零，这可以证明是因为您始终必须信任某些东西，而对它的信任可能会放错地方（例如，您要连接的其他用户将您所说的一切从他们的扬声器转发给其他人），但是这个想法安全的意思是说你的向量是小而少的，而不是大而多的，并且能够针对你知道的人（也许你不知道的人）准备具体的对策。

人们说凌乱的源代码是一个问题的原因有两个。

1. 在缺乏秩序的地方，很容易隐藏错误，任何错误都是潜在的利用。当然，没有任何程序，即使是看起来不错的程序，也完全没有错误（除非经过数学合理的安全审计以某种方式证明），但一个混乱的程序中可能有很多错误、空指针等。
   • 团队仍在努力使程序客户端正常运行，并且程序仍然经常崩溃、遇到错误和缺乏功能。
   • 粗略浏览一下源代码显示没有对任何客户端进行测试。
   • 大部分代码都是用 C Plus Plus 编写的——并不是说这种语言不安全，但这是一种因堆栈溢出、指针错误、内存溢出等而臭名昭著的语言。还有更好的语言，例如 Rust 甚至 Go，它提供了针对此类问题的更多基本保护。
   • 客户项目之间的代码风格截然不同。我并不是说风格不能不同，但这暴露了一个事实，即具有不同技能和编码标准的非常不同的开发人员正在做出贡献，并且没有称职的看门人说‘不，这个代码不符合我们的要求标准'
   • 构建系统过于复杂且充满潜在问题。虽然您可能对其中一个或另一个构建系统有一种特殊的感觉，但这个构建系统最多使用 5 或 6 个 - python、cmake、autotools、bash、g++、VC++。这意味着将非法依赖注入构建本身会更容易，并且纯粹通过数字增加项目污染的机会。
   • 它引入了大量的外部依赖项，这些依赖项本身的质量可能有问题。这是有道理的，但这也意味着，由于他们还没有开发和测试自己的视频解码/编码库，因此它们的质量和安全性仅与第三方库一样好。过去的许多 linux 安全漏洞都必须与具有晦涩能力的晦涩库有关，这些库具有可利用的错误，该错误将原本安全的系统变成不安全的 POC（废话堆）。
2. 没有明确方向或指导的碎片化开发
   • 客户端不是一个客户端，而是 6 个。有 2 个 Windows 客户端，2 个移动客户端，1 个 linux 客户端（虽然可能有 2 个，但令人困惑的是，该站点声明有一个 gnome 和一个 kde linux 客户端），以及一个 Electron/Web客户。这些客户端之间没有通用代码（不考虑 ring-lrc 和 ring-daemon），虽然团队认为这是不限制任何特定平台的更好“设计”，但这意味着它们不能很好地保证关于他们的平台好像支持 3 个客户端，例如 android、IOS、桌面。
   • 他们在代码中使用了多个非互补库。在同一个 linux 应用程序中，他们使用 GTK + QT，两者都提供相同的功能，并且是独立的工具包，不支持兼容性。这是错误的主要潜在来源。对于 Android 和 IOS 之间的根本不兼容性，没有太多工作要做（有人可能会争辩说，只有一个硬件移动平台会更安全——当然，如果设计得当的话）。Windows 客户端是 QT + GTK 应用程序和通用 Windows 平台客户端的一部分。
   • 在撰写本文时，只有一个 wiki 页面描述了如何构建项目。甚至关于客户端应该如何与客户端库或守护进程通信，或者应该如何修复错误或实现新功能的基本通用架构也没有方向。这意味着对于任何新开发人员来说，不仅要就如何实现某事做出明智的决定，而且要做出最终成为安全决定的决定，都将非常困难。

从网络/安全实现算法的角度来看，他们使用的一些库可能确实不安全、过时或完全损坏。上面应该是一个相当有说服力的库，即网络安全级别的工作更辛苦，并不比客户端 UI 层更好，而且可能处于更糟糕的状态。

一些想法，例如 DHT 或双棘轮算法可能是合理的安全想法，甚至可能有可用的安全原语，但这就是为什么我至少不会认为这个应用程序是安全的。如果我不能指望客户端做正确的事情，谁能说它不会被桌面上的一些非特权用户进程劫持，那么网络库做出的任何有效的安全保证都没有了？或者，如果他们使用的是旧的、不安全的网络库，就没有办法打开某些功能，从而无法使用安全算法？

话虽如此，如果您只想在许多平台上探索多媒体，这是一个有趣的项目，重点是安全算法作为一种“研究”项目，但它是否安全实施？几乎可以肯定不会。