在端到端加密中，服务器不需要被信任吗？

#1 楼

使用窃听程序（如WhatsApp服务器）在通道上进行端到端加密的方法是使用称为Diffie-Hellman密钥协商的数学拼写。接下来的内容实际上不是WhatsApp的工作方式*，而是探索一些高级思路来具体地回答问题，而又不会迷失该协议所有内容的详尽细节，从而防御了比您要求的威胁更多的威胁。

Alice和Bob同意使用公共参数$ p $和$ g $，†说$$ p = 2 ^ {2048}-2 ^ {1984}-1 + 2 ^ {64}（\ lfloor2 ^ {1918} \ pi \ rfloor + 124476）$$和$ g = 2 $。当爱丽丝（Alice）想与鲍勃（Bob）交谈时，她随机选择一个整数$ a $，其中$ 0 \ leq a <（p-1）/ 2 $均匀地随机化，将$ g ^ a $除以$ p $之后计算出余数， ‡写入$ g ^ a \ bmod p $，并在通道上传输$ g ^ a \ bmod p $。 Bob的操作与此类似：在相同范围内随机选择$ b $，计算$ g ^ b \ bmod p $，然后通过通道传输$ g ^ b \ bmod p $。
数学的非凡成就，是当爱丽丝收到$ g ^ b \ bmod p $时，她可以计算$（g ^ b \ bmod p）^ a \ bmod p $，结果与$ g ^ {ab } \ bmod p $。鲍勃做同样的事情：给定$ g ^ a \ bmod p $，计算$（g ^ a \ bmod p）^ b \ bmod p $，并获得与$ g ^ {ab} \ bmod p $相同的数字。 br />
没有人能想到一个非凡的数学壮举，它会让知道$ g ^ a \ bmod p $和$ g ^ b \ bmod p $但不认识$ a $或$ b $的人还可以计算$ g ^ {ab} \ bmod p $。

因此，Alice和Bob可以在通道上共享秘密$ g ^ {ab} \ bmod p $，而不向窃听者透露秘密是。然后，他们会将其哈希成一个短的秘密密钥，例如256位$ k = \ operatorname {SHA3-256}（g ^ {ab} \ bmod p）$，也许是SHA3-256，并继续将其用于对称密钥加密，例如AES-CTR。

但这还不是全部。如果这不仅是一个窃听者，而且是我们的朋友马洛里（Mallory），除了拥有一个令人讨厌的未命名名称之外，还可以主动拦截正在传输的邮件吗？ Mallory可以假装是Bob到Alice，而Alice到Bob，并做了一对Diffie-Hellman密钥协议，并与Alice和Bob建立了共享秘密，然后窃听了他们交换的所有消息。 WhatsApp服务器可以执行此操作。

为了阻止这种基于会话的共享秘密，Alice和Bob还使用了长期身份验证。爱丽丝像$ a $一样生成数字$ \ alpha $，并将$ g ^ \ alpha \ pmod p $放入电话簿中，或在电话屏幕上显示给Bob；鲍勃同样使用$ \ beta $。因此，它们具有长期共享的秘密$ \ kappa = \ operatorname {SHA3-256}（g ^ {\ alpha \ beta} \ pmod p）$。现在，当爱丽丝（Alice）想与鲍勃（Bob）进行对话时，她会执行每个会话的协议，但她不仅发送$ g ^ a \ bmod p $，而是发送$（g ^ a \ bmod p，\ operatorname {KMAC256} _ \ kappa（g ^ a \ bmod p））$。

当Bob收到候选消息$（A，t）$时，他首先检查$ t = \ operatorname {KMAC256} _ \ kappa （A）$处理之前。如果不是，他将消息放在地板上并忽略它。只有Alice和Bob可以计算函数$ \ operatorname {KMAC256} _ \ kappa $，因为只有Alice和Bob知道秘密的$ \ kappa $。

下一步，而不是仅使用$ k = \ operatorname {SHA3-256}（g ^ {ab} \ bmod p）$使用AES-CTR，他们使用AES-GCM加密和认证对话。 WhatsApp服务器可以翻转使用AES-CTR加密的消息中的位，而只有Alice和Bob知道秘密密钥，而Alice和Bob都不是明智的，但是不知道秘密密钥，WhatsApp服务器无法更改加密和删除消息中的任何内容使用AES-GCM进行身份验证，而不会引起Alice和Bob的注意。

如果爱丽丝和鲍勃因为从未真正见过面而无法在电话屏幕上交换$ g ^ \ alpha \ bmod p $和$ g ^ \ beta \ bmod p $，该怎么办？他们必须查阅WhatsApp出版的电话簿。当爱丽丝向鲍勃的长期公共身份密钥$ g ^ \ beta \ bmod p $咨询WhatsApp时，WhatsApp可以对其进行欺骗并撒谎，如果爱丽丝后来检查鲍勃的电话屏幕，她将检测到该诡计，因为它将另一方面，如果WhatsApp没有在电话簿中欺骗Bob的长期公共身份，那么Alice将在她的个人通讯簿中记住它。如果WhatsApp服务器在Alice尝试开始对话时曾尝试假冒Bob，则Alice会检测到该情况。这种身份验证模型有时称为TOFU，即首次使用时的信任。您还会在ssh协议中找到它。

有一个陷阱：有时Bob的身份密钥会更改，例如当他获得新手机时。在这种情况下，爱丽丝该怎么办？在Signal中，该应用不会代表爱丽丝发送任何新消息；它会通知她某事不对劲，并问她该怎么办。默认情况下，在WhatsApp中，§该应用程序将自动使用Bob的新身份密钥重试，以减少那些不了解该功能的用户的可用性障碍，从而导致主流媒体对该选项的报道陷入困境。如果它看起来像URL，那么它以某种方式使应用程序中一个更严重的漏洞泄漏了您所键入的文本。

最后，由于WhatsApp（是Facebook的一部分）提供了该软件并且不允许您对其进行审查，因此他们肯定有权阅读和模拟您的消息，他们很可能认真地认为自己不会滥用。这比让每个人都在爱丽丝和鲍勃之间的互联网路由上更好，例如跟缠扰者坐在与爱丽丝相同的wifi网络上的咖啡厅里几张桌子的缠扰者，这就是为什么监护人在呼吸时报告呼吸异常有害

即使您的电话通过固定证书向TLS传递了WhatsApp服务器的TLS证书，对电话簿进行恶意更改的审计跟踪也要比设计它容易得多通过WhatsApp服务器来窃听，从而设计审计线索，无论是利用软件漏洞的技术攻击者，不满的LOVEINT员工还是法院下令的窃听。

因此，第三方可以读取您的WhatsApp讯息？不，不太可能，WhatsApp本身会发起主动攻击（类似于Apple拒绝FBI进行的攻击），以使他们读取您的消息。声明使用信号协议（技术文档）。

†技术详细信息：$ p $是安全的素数，表示它是形式为$ p = 2q + 1 $的素数，其中$ q $也是素数$ g $是取模$ p $的二次余数，因此有序$ q $，这意味着当对任意整数$ x $除以$ p $时，$ q $可能有$ g ^ x $的可能余数。 $ g $模$ p $的幂构成了整数$（\ mathbb Z / p \ mathbb Z）^ \ times $的乘法组的子组。这对于您了解如何在公共渠道上共享秘密都不重要，但是如果您想进一步学习，我提供了一些关键词供您参考。

‡翘不实际计算，例如，2 ^ 13805771959684693407656077397889219317288456747119690312451189306384849479687628613222950288427889322679415500741971589068616989911210949597114445259398229588157002772876797268276100622563299377498600497546320786879884333079126581727906347769889606788799518360227168951984468071470187490408276074397578464837282521956615118563389889631151319459158126320262667606793413409480951816493115818911703426164912115254095626026747790743791560327229116656590818054138360168383331595495242709153295834514181328053967320381842712608527965926684083141420258332671624779764031721576291538707703835661166957458717002972300906725181，然后除以$ P $的结果;取而代之的是，她使用模块化的幂运算算法，以便可以在宇宙耗尽之前得到答案。

§其中一些是可配置的：认真使用用户，必须使用WhatsApp，例如新闻工作者，与消息源联系的是WhatsApp，应研究WhatsApp的隐私和安全选项。

#2 楼

有不同类型的加密。


对称加密

这是一个密钥用于加密和解密的地方，通常称为共享密钥。这是我们许多人从小就玩代码（技术上是密码）的时候所熟悉的。

要使用对称加密（例如AES），我们需要事先商定密钥，即


非对称加密

一个密钥用于加密，而另一个对应的密钥则需要解密。匹配的密钥被称为密钥对，加密密钥被称为公共密钥，解密密钥被称为私有密钥。

当爱丽丝想秘密地与鲍勃通信时，她会检索鲍勃的公钥（ （可以在互联网上发布），只有鲍勃及其相应的私钥可以阅读。这就解决了对称加密的问题，即必须首先在秘密上达成共识，而无需任何人进行窃听。

PGP使用非对称加密来加密用于消息对称加密的随机密钥。这种混合使用还避免了先安全地建立共享秘密的问题。


也有密钥协议方案


，这些类似于不对称密钥。加密。但是，它们允许2个用户通过不安全的通道（即使有人在窃听）建立共享的机密，而不是en和解密。

最常见的是Diffie–Hellman-Merkle。关于如何工作以及更重要的原因的数学运算有些繁琐，但请查看：https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Cryptographic_explanation。


现在，如果WhatsApp仅使用对称加密，那么您就认为密钥必须首先通过其服务器发送并且不安全是正确的。但是，WhatsApp使用信号协议，该协议基本上使用Diffie-Hellman建立共享的秘密会话密钥，然后将其用于对称加密（如果我没记错的话，是AES）。这样可以实现安全的端到端通信。

#3 楼

公开密钥加密技术恰好使您感到困惑：两方可以在窃听者监听的公共通道上提供共享的秘密密钥。普通英语的“ Diffie-Hellman密钥交换”提供了一些对此的简化说明。这就是如果您和您的联系人确实拥有彼此的公用密钥（不需要保密），那么您就可以通过公用渠道进行通信，而无需进行窃听或消息操纵。 />
，但这需要您和您的联系人实际拥有彼此的公钥，而WhatsApp无法独自完全解决这个问题。 WhatsApp在这方面提供的就是所谓的安全代码，您和您的联系人可以使用该机制独立地验证彼此是否拥有正确的公共密钥，而不是模仿者的公共密钥。使用这些安全代码和WhatsApp外部的受信任通信通道（严重！），您和您的联系人可以验证您的设备是否具有彼此正确的密钥。

从WhatsApp站点： >

什么是联系信息屏幕中的“验证安全代码”屏幕？

您的每个聊天都有其自己的安全代码，用于验证您的
呼叫和您发送给该聊天的消息是端到端加密的。

注意：验证过程是可选的，仅用于确认
您发送的消息是结束的-加密。

此代码可以在联系信息屏幕中找到，既可以是QR码，也可以是60位数字。这些代码对于每个聊天都是唯一的，并且可以在每个聊天的人之间进行比较，以验证您发送给聊天的消息是否是端到端加密的。安全代码只是您之间共享的特殊密钥的可见版本-不用担心，它不是真正的密钥本身，总是保密的。

要验证聊天是否已端到端加密


打开聊天。
点击联系人姓名以打开联系人信息屏幕。
轻按“加密”以查看QR码和60位数字。 60位数字。
如果您扫描QR码，并且代码确实相同，则会出现绿色的
复选标记。由于它们匹配，因此您可以确定没有人
截获您的消息或呼叫。 >可以向他们发送60位数字。让您的联系人知道
，他们一旦收到您的代码，便应将其写下来，然后直观地将其与“加密”下联系人信息屏幕中出现的60位数字进行比较。对于Android，iPhone和Windows Phone，您可以
使用QR码/ 60位数字屏幕上的“共享”按钮
通过短信，电子邮件等发送60位数字。


WhatsApp将此验证过程描述为“可选”，但如果您不验证联系人的安全代码（并且在WhatsApp之外进行验证），那么您确实可以信任服务器。从广义上讲，他们提供的是他们所能提供的最好的：您可以用来独立验证他们是否在做他们声称的事情的工具。但是他们实际上不能强迫您进行验证，而您必须自己进行验证。他们可以做的最好的事情就是使它更易于使用（例如，使用QR码）。

如果这在某种程度上使您感到烦恼，则应该养成在接触到联系人的安全码后便要进行验证的习惯。 Signal协议（WhatsApp使用的协议，它从Signal Messenger应用程序中采用的协议）的原则之一是，我们需要少数用户对安全代码保持警惕，以保护大部分用户免受不加选择的大规模监视。如果不时有足够的用户发挥作用，我们可以确信，WhatsApp的服务器在最坏的情况下只能用于针对狭窄用户群的目标监视。

#4 楼

即使通道不安全，端到端加密也是安全的，这很重要。您还可以通过不安全的渠道协商密钥。 />因此，如果客户端正确实施协议，那么正在侦听的人将无法获得协商的密钥。

但是我们仍然需要身份验证。所以我们知道我们在和谁说话。我们仍然依赖于Whatsapp，它们拥有公钥。设备在传输过程中对消息进行加密，以明文形式存储在设备上，然后备份到Google或Apple服务器。因此，即使WhatsApp无法阅读您的消息。 Google或Apple可能可以。

#5 楼

端到端加密安全取决于两个元素（上面已描述了两个）：


每个终端设备上加密的安全性和密钥交换的安全性算法

我怀疑终端设备是最弱的。

#6 楼

端到端加密（etee）的工作方式不涉及Whatsapp。如果是这样，那就是点对点（ptpe）加密。在etee中，双方基于较低的常见受支持/允许选项建立了关于算法等的共同协议，与浏览器对Web服务器的处理方式没有太大不同。

#7 楼

不完全是服务器，但必须信任您使用的整个软件系统。当然，数据可能已经加密，并且您也许可以验证，但是您无法证明密钥没有泄漏或有意传达给某些第三方。

#8 楼

如果所有通信都是通过不受信任的中介进行的，则无法安全地进行通信，因为中介可能会假装向每一方表示对方（中间人攻击）。因此，假设双方不能/不想直接通信，即使交换密钥的程度也是如此，确实需要对服务器进行一定程度的信任。方案（在其他答案中有详细描述）是安全的，只要中介机构不主动干预通信即可（即在服务器可能窃听消息但会如实转发的前提下是安全的）。由于如果双方直接交谈，很容易检测到干扰，因此攻击者尝试冒险是有风险的，因此在实践中不必过多担心。

#9 楼

您真正需要的是确保您的公钥和其他方确实正确传输。确保这一点的唯一方法是在您信任的设备（最好是模拟设备）上亲自和物理地交出公钥。该技术显然存在（如果我愿意的话，我可以从技术上讲）可以自适应地在开放的互联网交换机公钥中传输伪造的公钥，以允许MITM攻击（如果您只是贿赂合适的人）。


一旦成为父母，您将很容易受贿。同样，世界上大多数投票者都是父母，因此很幸运在民主框架内改变任何一种投票方式。

#10 楼

如果它不是端到端加密的，那根本就不是真正的加密！在明文旁边写密文等同于信息方面的信息，与仅写明文并删除密文等效。即：如果解码的内容在您眼前，请勿解密。将密钥写在密文旁边只会好一点。他们只是将两者结合起来就得到了纯文本。静态加密比较好一点，因为密钥不在磁盘上。但这通常意味着该密钥确实通过了该计算机，并且该计算机可能已将该密钥注销了某个位置（即：写入了一个S3桶加密密钥）。端到端意味着机器从未见过密钥，并且不执行必须在用户机器上停顿的加密/解密...。 -end是您遵循加密的第一条规则的唯一方案……不将密钥提供给不应解密的人。确实拥有密钥的“静态加密”取决于绅士的同意，而不是简单地记住密钥或密文。