基于区块链的端到端加密通信

端到端加密通讯的基本原理

端到端基本上都是基于非对称加密手段来实现：假设通讯双方为A和B，AB都 自己生成一个随机的 私钥（p） 并私密地保存起来，然后通过数学算法，生成一个 公钥 （L），把公钥发送给想要跟自己通讯的点（peer）。当他们要给对方发送信息的时候，将信息用对方给的公钥进行加密，然后通过网络发送到对方；此时对方可以用已保存的私钥，解密加密后的数据，得到信息原文，实现了信息在传递过程的私密性。用描述语言如下：

A gen  pA/LA, store pA, send LA to B
B gen  pB/LB, store pB, send LB to A

发送消息时:
A.sendTo(encrypt(message, LB), B)，发送的是用B的公钥加密过的信息。
B给A发送的状况类似。

接收消息时:
B.receiveFrom(A).decrypt(pB)，接收到A发过来的加密信息后，用B的私钥解密，得到信息原文。
A 接收到加密信息之后的处理方式类似。

有中心化服务器的加密通信

目前已有的端到端加密通信手段有： WhatsApp、Telegram等。其宣传通信都是通过端到端加密的，即使中间服务器也无法知道端之间在沟通什么内容。当然这都是扯蛋，不想知道和不能知道是两回事，很明显这两者只是把自己的形象往前者靠，至于后者嘛，由于有中间服务器的存在，而且有为了提升用户体验，端之间的公钥都是通过中间服务器交换的，这也就给中间服务器带来了中间人攻击的可能。那么开源能解决这些信任问题吗？其实也不行。现在，即使WhatsApp、Telegram将他们的代码开源出来，也解决不了问题。为什么呢？ 因为代码开源跟实际程序的运行是两回事，完全可以开源一套代码，运行时是另一套代码，因为节点都是一个中间实体控制的，其他人无法做审计。那么，如果他们开放给所有用户去审计他们运行的程序，有用吗？也没用。从技术上讲，即使我运行时的程序是从开源的代码构建出来的，作为一个恶意的节点，还是有机会把数据拿出来的。比如很多程序语言有监听代理的机制，通过一个挂载在程序之外的agent，可以把程序的运行的所有数据拿出来。再退一步讲，即使没有agent的技术，黑客（或者恶意方）依然可以通过计算内存的数据，把信息拿出来。 除非端到端之间的通信，是不经过中间服务器的，类似bittorrent这种P2P技术，无需中间服务器，端到端直接实现通信，才能进一步提升加密的安全性。

去中心化的加密通信

基于类似闪电网络的通信机制，在理论上是可行的，目前有Sphinx.chat据说就是基于闪电网络构建的P2P加密通信。网络本身做一个中继（relay），端到端之间通信做加密，没有任何中间节点可以窃取信息（窃取了，因为没有解密手段，也没啥用）。这里不是纯粹的P2P通信，而是通过中间的中继网络（relay）去传递信息，比P2P通信的私密性更上一层。 Relay网络中间的任何节点并不知道信息的原始发起方（source）和最终接收方（dest）是谁，所以他们的网络日志也审计不出哪些端口（endpoint）之间做了实际的通信，需要全节点的数据才有可能分析出来，成本不低。但这一切基于，端与端之间的公钥的确定性。 假如网络内有两个节点A、B要通信，他们如果通过Relay网络来发送他们的公钥给对方，那么他们的信息还是有可能会被窃取的，这个就是经典的加密通信中的MITM attack（中间人攻击）。

A gen  pA/LA, store pA 
A.sendPublicKeyOverRelayNetwork(LA, B) //通过中间网络发送公钥LA给B

为了简单起见，我们假设中间网络只有一个（恶意）节点，这个节点叫C
那么C在接到A的发送公钥的请求时，他完全临时生成一个 私钥（pC）、公钥（LC）对，先把A的公钥保存起来，然后替换掉A的公钥，实际发送给B。


B接收到的公钥实际被篡改成c的公钥了，B给A发送信息时
B.sendOverRelayNetworkTo(encrypt(message, LC), A)

C作为中继网络节点，收到B发送的加密信息之后，用C的私钥将信息解密成原文，然后再用C之前保留的A的公钥进行加密，再发送给A
C.sendTo(C.receiveFrom(B).decrypt(pC), LA), A)

这时，A收到C发送的信息，也能正常用自己的私钥pA进行解密，实现所谓了的『加密通信』。但实际上所有的信息都被C窃取了。

所以说，当年Google作为一个大平台，提出Don’t be Evil 确实是非常有挑战的愿景。

那么A/B之间如何保障这个公钥不会被中间节点C替换呢？

1. 基于区块链的公钥安全分发能力

通过在区块链网络引入CA的能力，通过一个可信的CA签发证书，那么AB拿到公钥的时候，都可以通过CA来验证该公钥的真实性。 可惜的是，去中心化的世界里，不存在CA，因为大家都默认中间节点不可信，很明显在这里，CA就是一个中间节点。 如果CA和某个恶意中间节点窜某，那他们依然可以窃取A、B的加密信息。那么在区块链中，引入一个去中心化的CA能否解决这些问题呢？上一篇讲关于DID的文章里，我们知道其实区块链完全可以作为安全的公钥分发渠道。 区块链的存储能力最牛逼的点是防篡改，那么A/B本身都可以把自己的公钥，公布到区块链上，然后大家去区块链中找到已被确认的信息，就能找到A、B的公钥，这样也能实现加密通信。难点在于，数据上链的过程，区块链是无法保障数据本身的真实性的（区块链只能保证数据上联之后不会被篡改，不能保证数据上链之前的数据是否真实准确，就类似于很多区块链的场景用于做溯源跟踪的窘境类似）。如果A、B在通信网络上的ID和链上的ID能通过公开的数学算法能一一对应起来，这种暴露公钥的方式，就能行之有效。比如 A 通过自己的区块链帐户，发布了一条公钥存证信息，除了公钥本身，A的帐户地址也很重要。如果通讯网络的A、B的ID和区块链上的ID无法一一对应，那么一切都没那么安全。比如 恶意节点C，也在公链上发布一条公钥信息，并声称该公钥是A的（或者B的），那么A、B是无法验证这消息的真实性的，因为他们的不知道公钥产生的地址（帐户ID）如何与通信网络上的帐户ID对应起来，那么可能他们之间的通信，依然会被恶意节点C窃取。公钥在区块链上暴露的问题解决了，会导致另一个问题：因为公钥被公开，所有人都可以用公钥来伪装成一个你认识的人来跟你通信，这种会造成通信诈骗等其他问题。在中心化的网络中，CA能起作用，是因为他能校验信息提供的来源（IP地址或者域名），而基于中继网络，你可能无法识别内容的真实来源是否是你期待的那一边。但在区块链网络中，所有人就是自己的CA根，因为区块链网络依赖于签名运作。首先我们知道，区块链的帐户地址由私钥控制，私钥通过一定的算法推导出公钥用于做签名验证，而公钥在经过一定算法可以推导出帐户地址。所以AB在发送消息的时候，对自己发送的消息，用自己的私钥进行签名，加密信息联同签名一起发送给对方。这样对方在接受到信息的时候，可以先验证，消息是不是来自于对方的（用发送方在区块链上公布的公钥，验证发送过来的签名），然后在用自己私钥解密对方通过己方公布的公钥进行加密的消息，实现消息的解密。整个过程既实现了消息的加密安全，又增强了消息来源的验证能力，这样一来中间节点就完全失去了窃取的能力。

2. 基于传统多通信渠道的公钥分发能力

比较传统且用户体验较差（但行之有效）的方式是， A和B都各自生成自己的公私钥对，然后发送公钥的时候，用其他的无关渠道发送（例如通过传统的邮箱、短信、甚至WhatsApp等发送公钥给对方），然后对方用这个公钥来做信息的加密并发送，从而避开了单一网络的中间人攻击问题。当然，如果发送公钥的渠道和恶意节点串谋，也是存在安全性问题的，只能说这种被攻击的概率会比直接在relay网络上发送公钥的方式低的多。如果再加上分散几个网络，分别发送部分的公钥，那么中间恶意节点要串谋这么多的渠道实现信息的窃取的概率就更低了。（例如通过不相关渠道1发送某种算法加密过的公钥密文，然后通过不相关渠道2发送对应算法的解密密码）这种情况，对想实现真正私密通信的双方，通信建立的初期成本都是非常高的，用户体验上很难接受。

综上，其实1的方式，虽然暴露了公钥（但既然是公钥就不怕公开），需要一定的成本（数据上链，需要发送服务费+时间成本），但他是综合来讲是用户体验比较好的方式。当然这里的用户体验好是有要求的，就是沟通双方需要依赖于某种特定区块链的帐户算法体系，例如用比特币区块链， 那他们联调用的账号其实和比特币钱包是一个账号。这样又能联调又能发送「红包」给对方，瞬间跟微信有点像了。（需注意的是，对于消息加密解密的公私钥最好不要和区块链地址的公私钥相同，因为一旦这聊天类的私钥泄露了，也可能导致你的帐户资金被盗）

后话

端到端加密通信，核心诉求是加密本身，而通信的中间渠道是通过点对点还是中继网还是公开的云网络，问题都不大。只要保障端到端的非对称加密和签名验证通信，就能实际完全私密的加密通信。在非对称加密中，公钥的分发渠道需要谨慎选择，而区块链（公链）天然就具备公钥分发的属性，所以非常好解决。另一个存在的问题是discovery问题，这个理论上通过区块链的地址，互相扫码也能添加，就是建立通信的初期，还是得面对面添加（确保地址的正确性），其他问题都不大。区块链网络也能作为discovery网络而存在，就是用户在选择对方的时候，需要做一定的checksum，保障不要选错人。至于中间的转发渠道，通过协议设计以及去中心化，确实可以再次提高通信的安全性。