参考文献：

* Jarecki S., Krawczyk H., Xu J. (2018) OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-computation Attacks. In: Nielsen J., Rijmen V. (eds) Advances in Cryptology – EUROCRYPT 2018. EUROCRYPT 2018. Lecture Notes in Computer Science, vol 10822. Springer, Cham.

* CFRG, The OPAQUE Asymmetric PAKE Protocol, draft-irtf-cfrg-opaque-latest.

* Tatiana Bradley, OPAQUE: The Best Passwords Never Leave your Device, cloudflare blog.

* Cloudflare, OPAQUE DEMO, opaque.research.cloudflare.com

本文并非完全原创，本文部分文本的权利归参考文献的作者所有。

什么是“口令认证密钥交换”

一般来说，密钥包含较大的信息量因而不方便记忆，而口令则需要能更方便记忆。而口令认证密钥交换(PAKE)旨在解决这样的问题：通信双方，在仅共享某一口令的情况下，如何建立密钥。

PAKE协议为目前常见的网络和web应用程序提供了一种认证思路，但传统的口令认证(也包括非PAKE思路)却需要在服务器端存储，或在认证时向服务器传输明文口令。

“非对称”口令认证密钥交换(aPAKE)则意在解决这一问题：有没有一种方法，可以在通信的一方完全无需知道明文口令的前提下，却依然可以完成认证呢？如果这样的协议可以实现，那么口令(密码)将完全无需离开用户本地，因而口令泄露事件得以完全杜绝。

不过，传统的aPAKE思路依然存在一定缺陷。如果口令-密钥映射是确定的，或者仅通过明文随机盐来提供不确定性，那么攻击者就可以通过预计算(例如彩虹表)的方式根据密钥计算口令：这抵消了aPAKE所提供的部分好处。

而OPAQUE，通过将oblivious pseudorandom function(OPRF*，忘性伪随机函数，不经意伪随机函数)和aPAKE算法相结合，提供了一种能抵抗预计算攻击的思路。

IRTF(国际互联网研究任务组)的CFRG(密码学论坛研究组)正在完善一份将OPAQUE协议用于互联网的草案。这份草案一旦完成，便会由ietf发布为rfc，从而进入互联网标准。

因为草案尚未完成，本文不会就协议细节做过多介绍。

点赞过10更OPRF(人家都是过10万我这里10都过不了T_T)

以及oblivious这首歌很好听

OPAQUE的流程

Cloudflare实现了一个OPAQUE流程的实例程序，链接可以在参考文献中找到。

OPAQUE算法分为两个过程，注册和登录。

注册流程

注册流程发生在客户端C和服务器端S之间。这一过程要求S和C能够相互确认(就是说，用户要确认对方不是钓鱼网站，网站(如果有需要的话)要能确认用户身份)，这也是OPAQUE唯一需要经认证的信道流程。

• 在开始时，C需要准备好口令password并生成一对密钥对*creds。C对于每一个账户都应当生成新的密钥对。S需要预先准备好密钥对server_private_key和server_public_key。S可以对许多不同用户使用同一密钥对。

• “密钥对”是一个词，指互相对应的公钥-私钥组成的一对密钥。

• 之后，C将口令随机化得到(r, M), 并将M发送至S。

• S在收到请求后，需要生成OPRF私钥oprf_key，然后使用oprf_key处理M得到Z，并将Z返回。

• C使用返回的Z，明文口令password和第一步得到的r计算Y。之后，C将creds私钥用Y处理，得到经过加密的私钥，然后和明文的creds公钥一起返回至S。S将C的明文公钥，加密私钥和oprf_key一同记录账户中，从而完成注册流程。

登录流程

登录的第一步，是C根据明文密码取得私钥并解密。

• 首先，C根据明文口令password计算(r, M)，需要注意的是这里的(r, M)每次都是不同的。之后，C将M发送至S。

• S使用M和oprf_key得到Z，并将Z和加密私钥共同返回。

• C使用Z，r，password计算Y。如果password正确，每次得到的Y应当是相同的。C使用Y解密加密私钥，从而将其恢复为明文私钥。

• C仅使用密码重新得到私钥，从而进入登录的下一个环节。

之后，像传统的登录流程一样，C和S通过密钥对creds建立会话。会话成功建立从而登录流程结束。

当然，适用于OPAQUE的“下一步”和传统的流程并不完全相同，CFRG建议了包括3DH和SIGMA-I等在内的一些选项，而根据Tatiana Bradley的研究，TLS也是可用的。

整个流程中，S只接触了由口令随机化得到的M，却并没有接触明文口令，而M值每次都是不同的。C仅仅在登录时生成了creds，并将其加密后转交S存储。OPAQUE实现了在C端不存储私钥，而是在登录时根据口令恢复私钥；同时在S端不存储口令，而是存储OPRF私钥和加密的用户私钥。从而完成了aPAKE的要求。由于OPRF流程的使用，OPAQUE能够有效对抗预计算攻击，从而在服务器遭受入侵或泄露的情况下依然能保证用户凭据的安全。

(翻译论文和rfc好累啊T_T)