禁止端对端加密是愚蠢的
不同国家的众多立法者提议要求即时通讯服务提供一种机制,使执法部门可以解密端对端加密的信息。
这种立法从根本上误解了坏人构建自己的端对端加密层叠加在其他即时通讯系统之上是多么容易。
要求Signal、WhatsApp等引入漏洞并不会为犯罪分子带来太多困难。 他们可以轻易地构建或购买额外的加密层,交换无法解密的信息。
但这确实会让其他人更不安全。 如果存在一个后门,并且可被授权人员使用,它终将被恶意人员利用。
这个仓库包含了一个简单的示例,展示了如何通过任何即时通讯服务,包括普通的短信服务(尽管消息长度限制可能会造成问题),发送端对端加密的信息。 这个程序只有186行代码(依赖一些现成的开源库),编写只用了大约一个小时。
让我们假设Alice想给Bob发信息,就像密码学文本中常见的情况。 她需要一个秘密密码短语,用于派生一些密钥:
$ cat pass
Alice has a totally secret passphrase.
这就是保持端对端加密所需要的唯一秘密。不必担心它是如何使用的,只要记住这是一个没人能猜到的秘密就行了。
然后她运行以下命令:
$ banning-e2ee-is-stupid -k pass -u bob
程序发现这是Alice第一次给Bob发信息,所以会要求Alice提供她的公钥,并要求Bob提供他的公钥。 它们会以一串英文单词的形式输出:
You have not exchanged keys with this user. You must send them your public key:
celan fiona tasmanian bloomer terminological elca glamis fenceposts troilus ramapo premeditation meth chairpersons addictiveness bergman beauregard
Please enter their key:
与此同时,Bob也准备接收来自Alice的第一条信息,所以他确保有一个完全无法猜到的密码短语,并运行该工具来解密一条消息:
$ cat pass
Bob also has a completely unguessable passphrase
$ ../banning-e2ee-is-stupid -k pass -u alice -d
You have not exchanged keys with this user. You must send them your public key:
luxuriantly hensel soper chinny kilts esai downpours dissimulation adroitly widmann striven breastbone clonmel forecastle abascal barstools
Please enter their key:
Alice和Bob必须相互交换他们的公钥。最简单的方式是通过短信或电子邮件发送,然后通过电话读出来。这不是秘密:如果有人读取了这个密钥也没关系(你可以把它放在网站、Facebook个人资料等任何地方),关键是不能被篡改。
这个密钥交换过程是由Signal这样的应用程序自动处理的。做好这一部分是构建端对端加密即时通讯应用程序的关键所在。一旦Alice和Bob都粘贴了对方的公钥,他们就可以开始交换消息了。不会再被要求输入密钥。 Alice现在会看到这样的内容:
Please enter the message to encrypt:
Hi Bob!
Send the following message to the other person:
anomaly forceful amongst ralphie gia ponds scandalous movies ungracious candidate absolution honan lima lambent cutaways embroider locos computers disqualify boehm naik brimming schrieber glebe
这条消息现在已经被加密,只有Bob才能解密。 Alice现在可以将这条消息通过电子邮件、她最喜欢的即时通讯程序发送。她甚至可以将其粘贴到GitHub Gist或Pastebin等公开平台上。 除了Bob,其他人都无法解密它,而Bob可以检测到是否被篡改。事实上,Alice可以在不同的地方粘贴多条随机消息,Bob可以尝试解密它们,找到那条属于自己的。
Bob只需要将Alice发来的消息粘贴到程序中:
Please enter the message to decrypt:
anomaly forceful amongst ralphie gia ponds scandalous movies ungracious candidate absolution honan lima lambent cutaways embroider locos computers disqualify boehm naik brimming schrieber glebe
Decrypted message:
Hi Bob!
如果消息被篡改、不是来自Alice或不是发给Bob的(这三种情况无法区分),程序会报告"解密失败"。
通过这个简单的程序(记住,只花了大约一个小时的编写时间),Alice和Bob就可以通过任何不安全的渠道交换信息。 这是一个用于演示在一个未加密的信息服务上建立加密信息传输有多么简单的小型演示程序。
十多年前,TextSecure就开发了一个产品实现了这一功能(使用了更聪明的加密技术!)并提供了一个精美的用户界面。
在此之前,OTR为各种未加密的即时通讯网络提供了插件,允许端到端加密(同样具有比这个演示更强的安全性能)。
这些都是提供安全的端到端加密信息传输的精细客户端,使用了现有的信息网络作为不安全的传输通道。
- 它不尝试使密码短语存储安全。 好的代码应使用操作系统的密钥存储API。
- 它没有提供轮换密钥的机制。 良好的系统会定期重新生成密钥以应对密钥泄露的情况。
- 它没有提供前向安全性。 如果你的密钥泄露了,攻击者可以冒充你并读取你收到的所有消息。
- 它没有保护内存中的密钥。 密钥可能会出现在核心转储、交换空间等中。
- 没有人审查过加密的使用。 我不是密码学家,我可能做了一些愚蠢的事情。
- 它使用随机依赖项。 SQLite和libsodium包装器是因为它们是DuckDuckGo搜索的第一个结果而被选择的。 这不是进行供应链安全的正确方式。