OPAQUE Protocol: Let's overcome the inconveniences of Web3 with semi-decentralization
What is the opaque protocol, and semi-decentralization? How can it be used in blockchain?
⁉️ Are you curious about what OPAQUE protocol and semi-decentralization are?
The OPAQUE Protocol, defined in RFC-9807, is a cryptographic protocol for client-server architectures that allows secure user registration and sign in without ever revealing the client's plain password to the server. In this respect, the OPAQUE Protocol shares similarities with Zero-Knowledge Proofs(ZKP). Furthermore, it enables data to be securely stored without being disclosed to the server by encrypting it with a key known only to the client which derived from the protocol.
I define "semi-decentralization" as a system where data resides on the server(centralized), but the sovereignty over that data rests with the user or community(decentralized). The OPAQUE Protocol embodies this semi-decentralized nature because, while data is stored centrally on the server, access and manipulation rights are exclusively granted to the user.
💪 Can semi-decentralization overcome the inconveniences of Web3?
The current user experience (UX) in Web3 is, admittedly, not as seamless as in Web2. I believe that a semi-decentralized approach offers a crucial interim step to bridge this UX gap.
For instance, Solana has made all its block data accessible via Google Cloud(centralized) for faster access. This data is centrally stored in the cloud, but because it's generated and maintained by the Solana community and accessible to all users(decentralized), I consider it semi-decentralized. Similarly, Hyperliquid employs a comparable method by uploading data to AWS-S3.
Another example is Ethereum Layer 2 solutions. Here, a sequencer processes all transactions(centralized) and records them on the Ethereum mainnet. However, the fact that anyone can verify these transactions and access the data(decentralized) makes this approach semi-decentralized.
As the examples above show, a hybrid model of centralization and decentralization allows us to gain the benefits of throughput and easy access without significantly losing decentralization.
🤿 Deep Dive into Opaque Protocol Step-by-Step
The OPAQUE Protocol primarily consists of two phases, employing the OPRF (Oblivious Pseudorandom Function) protocol to generate unpredictable randomized password:
Registration (Sign-up)
Online Authenticated Key Exchange (Sign-in)
Before these two phases begin, server setup is required. Let's examine the step-by-step process, from setup through each phase, noting that many details are omitted to make it more intuitive.
0. Server Setup
The server prepares a public/private key pair and an OPRF seed (necessary for using the OPRF protocol).
1. Registration
This phase involves storing the client's randomized password on the server.
Step 1: Registration Request
The client generates a blind element for the OPRF protocol from their password.
This blind element is sent to the server along with a user identifier (e.g. username).
Step 2: Registration Response
The server uses the received blind element from the client and its own OPRF seed to generate an evaluation element.
The evaluation element and the server's public key are then sent back to the client.
Step 3: Record
Client
The client uses the password entered in Step 1, the blind element generated in Step 1, and the evaluation element received from the server to obtain the OPRF function's output, which is used as the randomized password. An export key is extracted from this randomized password. The randomized password, along with other supplementary information, is then bundled into an envelope and sent to the server.
Server
The server stores the received envelope using the user identifier as a key.
Client Server
---------------------------------------------------------------------
(user_identifier, blind) = CreateRegistrationRequest(password)
Registration Request
--------------------------------------------->
(server_public_key, evaluation) = CreateRegistrationResponse(server_public_key, blind, oprf_seed)
Registration Response
<---------------------------------------------
(envelope, export_key) = FinalizeRegistrationRequest(password, blind, evaluation)
Record
--------------------------------------------->
2. Online Authenticated Key Exchange
This phase requires going through the OPRF process once more to retrieve the randomized password obtained during registration. It's a process where the server and client exchange and verify each other's keys, subsequently generating an identical session key for future communication. The exchanged ke(key exchange) messages that appear at each step facilitate key exchange and verification between the client and server.
Step 1: AKE Message 1
Similar to the registration process, a blind element is generated from the password.
A ke1 message is created.
The blind element, user identifier, and ke1 message are sent to the server.
Step 2: AKE Message 2
The server uses the received blind element from the client and its own OPRF seed to generate an evaluation element.
The server then finds the envelope corresponding to the user identifier.
A ke2 message is created.
The server's public key, the evaluation element, the envelope, and the ke2 message are sent to the client.
Step 3: AKE Message 3
Client
The client uses the password entered in Step 1, the blind element generated in Step 1, and the evaluation element received from the server to obtain the OPRF function's output, which is used as the randomized password.
The client then uses this randomized password to open the envelope and extract the export key.
A ke3 message is generated, and during this process, the client's session key is created.
The ke3 message is sent to the server.
Server
The server generates its session key from the ke3 message received from the client.
Client Server
--------------------------------------------------------------
(ke1, blind) = GenerateKE1(password)
AKE Message 1
---------------------------------------->
(server_public_key, ke2, evaluation, envelope) = GenerateKE2(server_public_key, blind, oprf_seed, ke1, envelope)
AKE Message 2
<----------------------------------------
(ke3, export_key, session_key) = GenerateKE3(password, blind, evaluation, envelope, ke2)
AKE Message 3
---------------------------------------->
Ultimately, if the export key from the registration process matches the export key from the login process, and the client's session key matches the server's session key, the OPAQUE Protocol procedure concludes.
Subsequently, the session key is used for encryption and decryption during communication between the client and server. The export key is a key known only to the client and is used to encrypt data before storing it on the server, ensuring the data remains confidential from the server.
Example of session key and export key Usage
Client encrypts data with export key → Client encrypts with session key → Server decrypts with session key → Server stores data
Server encrypts with session key → Client decrypts with session key → Client decrypts with export key → Client reads data
🔐 Security Analysis
By using an unpredictable randomized password derived from the password via the OPRF protocol, pre-computing attacks like rainbow attacks are prevented.
To prevent client enumeration attacks, the same oprf seed is used for all users, making it impossible to distinguish between unregistered and registered users. However, client enumeration attacks during the registration process cannot be entirely prevented, so applications must implement various restrictions during registration to mitigate this attack.
Even if the server is compromised and records are leaked, all data is encrypted, thus protecting the information. Furthermore, a Key Stretching Function (KSF) is applied to the OPRF output (randomized password), significantly increasing the cost of an attack.
The export key should only be used after verifying the authenticity of the server (i.e. after the login process is complete).
To prevent a fake server from impersonating the legitimate server by stealing records, it's crucial to verify that the server public key obtained during registration matches the one obtained during login. 👉 ShardLab offers an OPAQUE Protocol library that incorporates this functionality using WebAssembly.
🤩 OPAQUE Protocol in Blockchain
Recently, the blockchain domain has seen a growing adoption of semi-decentralized approaches, beyond just Solana, Hyperliquid, and Layer 2 solutions. The OPAQUE protocol, another semi-decentralized method, isn't yet widely adopted in the blockchain domain. However, it's clear that, like other semi-decentralized approaches, the OPAQUE protocol could bring a significantly improved UX in the Web3 user authentication, offering both security and convenience without largely sacrificing decentralization.
“If you are a Web3 developer, why not consider using the OPAQUE Protocol for better security and UX?”