在上一篇文章中，我们提到了证明者需要让验证者相信TLS响应是从某个特定服务器发送的。

DECO包含以下三个部分，即：证明者（Alice或简称“她”）、验证者（Bob或简称“他”）以及TLS服务器（Charlie或简称“它”）。在TLS协议中，客户端（注：在DECO中客户端就是证明者）在每一轮新的会话中会发起秘密挑战，以验证服务器的真实性。TLS是交互式协议，因此验证者需要参与协议执行才能验证数据的真实性。他会作为证明者和服务器之间的代理，记录在TLS协议中传输的字节。在之后证明数据真实性的环节中，这些字节就是证明者和验证者所知的“事实”（truth）。这里需要注意的是，TLS协议可以确保数据无法被“偷听”到，也就是说验证者无法偷听到数据。

服务器完全不知道自己参与了DECO协议。这就需要在执行时不对TLS协议做任何修改，而DECO则需要严格按照TLS协议的每一步执行。首先，证明者会生成TLS会话密钥。然后，再用这把密钥来解密TLS密文。

在TLS协议一开始，证明者和服务器会使用密钥交换协议（如：Diffie–Hellman）来生成一个TLS会话密钥K，而验证者并不知道K是什么（注：否则就无法保障TLS的安全性）。不过这里存在一个安全漏洞：假如证明者在后续ZKP证明中使用假密钥K′怎么办？这是完全有可能的，因为在现代TLS协议中，加密算法中的密文可以用好几种方式解密。证明者可以将密文解密成服务器之前从来没发送过的内容，而这样做会破坏数据完整性。DECO给出的解决方案是让证明者提交一份绑定密钥的证明，以证明对会话密钥做出的承诺[K]是有效的。

之所以提出这个要求，是为了让证明者向验证者证明，会话密钥K是与验证者记录的会话一对一绑定的。要了解其底层逻辑，首先得了解TLS会话密钥是如何创建的。

我们将用[GZBW22]的TLS 1.3简化版来举例（注：为了方便大家理解，我们将省略证书验证环节，并将多个密钥统一用K来表示）。首先，证明者和服务器会生成一个共享秘密（secret），验证者看不到这个秘密，我们称之为S。然后，他们会在本地基于S计算出密钥K。在下述协议中，HMAC指散列消息认证码（Hash-Based Message Authentication Code），HKDF指HMAC密钥派生函数（HMAC Key Derivation Function），而HASH则是哈希函数。

而在这些中间环节的数值中，服务器只向证明者发送SF。证明者对收到的SF进行验证，查看是否匹配本地计算出的数值。

验证者观察并记录A、B以及SF，并同时知道g和p。他无法计算出K，因为他不知道a和b。要验证[K]是否正确，一个最直接的方式就是证明者将秘密a作为ZKP中的隐私输入来对其作出承诺。然后，证明者和验证者利用已知的数值，可以通过ZKP协议计算出[K]。这个方法虽然很安全，但成本也很高，因为公钥的执行电路（即：计算A和S的模幂）包含大量的与门（AND gates）。

[GZBW22]利用了哈希函数的抗碰撞性（collision-resistance）来优化这个电路。在优化的版本中，证明者不是对a，而是对S做出承诺，因此ZKP电路只需要包含第六到十步。由于验证者已经作为代理在记录SF，因此证明者在第八步后会打开[SF]，而验证者则会将[SF]与记录的数值进行对比。哈希函数具有抗碰撞性，因此可以确保证明者无法计算出错误的S≠gab mod p并算出同样的SF值。经过这样的优化后，我们就可以避免在ZKP协议中执行公钥操作，而是只涵盖HMAC和HKDF这两项。HMAC和HKDF中计算最密集的部分就是多次哈希运算（如：SHA-256）。这个哈希函数的电路非常大，但是由于近期交互式ZKP技术取得了一定进展，因此还是可以在合理时间内完成的。

需注意的是，TLS会话中包含多个密钥，不同TLS版本的密钥数量也有所不同。TLS 1.3版包含四个密钥，handshake和appdata中两个方向各有两个密钥。第十步中的K就是从服务器到证明者的appdata密钥。第六到第十步在相反方向中也会重复一遍。在下一章以及后续文章中，我们会具体讲解服务器到证明者的appdata，即：TLS响应。本系列的最后一篇文章会详细讲解证明者到服务器的appdata，即：TLS请求。DECO还会双向验证handshake密钥。

证明者和验证者就密钥达成一致协议后，会持有对TLS会话密钥K做出的承诺[K]以及服务器发送的加密TLS响应C。证明者收到C（即：TLS客户端），而验证者则作为代理将其记录下来。在之后证明数据真实性的环节，C就是证明者和验证者都知晓的“事实”（truth）。

证明者和验证者首先会计算对TLS响应R做出的承诺[R]。要做到这一点，他们需要通过ZKP协议执行解密电路R=decrypt(K,C)，其中[K]和C是输入的参数。TLS支持许多不同的密码套件，decrypt()的具体内容会根据每一轮会话所选的密码套件而有所差异。在顶层，decrypt()会基于响应的长度反复调用一个对称加密函数（如：AES-GCM-128）。在DECO与Teller的一个概念验证应用中，为了解密一个响应（即：证明者的财务报告），大约调用了1700次AES-128函数。解密一个区块（大小为126B）的AES-128电路包含6400个与门。也就是说，计算[R]需要计算对超过1000万个与门输出做出的承诺。储存这么多承诺对于内存的要求是巨大的。索性，commit-and-prove ZKP能够忘记之前的承诺，因此我们只需要储存一个AES-128电路的承诺即可，其大小不超过1GB。更重要的是，对内存的要求跟对AES-128电路的调用次数没有关系，因此也跟TLS响应的大小没有关系。

在这一步中，证明者和验证者会持有对TLS响应做出的承诺[R]。验证者相信响应是真实的，因为响应来自对加密TLS响应C的解密，而这个C是验证者作为代理记录下来的，而且他使用承诺的密钥[K]验证了计算的有效性。在下一篇文章中，我们将讲解如何解析一个已经验证过的响应。

这是Chainlink Labs研究团队发布的DECO深度研究系列的第二篇文章。欢迎查看本系列的其他文章：

‍