Modified Okamoto identification

All roles run locally in this browser. Secret scalars are displayed for explanation only; they are not protocol messages. This is a research demonstration, not a production service.

Loading MCL WebAssembly...

Construction and implementation

Functional demonstration of Security of Okamoto Identification Scheme: a Defense against Ephemeral Key Leakage and Setup. Cryptographic operations run locally using MCL WebAssembly.

Original and modified Okamoto

The commitment and challenge keep their roles. The change is in the response: the original protocol sends a linear expression as a scalar; the modified protocol sends that expression in the exponent, under a base bound to this commitment and challenge. A pairing checks the relation without receiving the scalar.

Original Okamoto identification on the left and its modified, pairing-verified variant on the right. The modified response is a group element instead of a scalar. — Author's original comparison artwork. Multiplicative notation; see SCC 2017, Sections 3.2 and 4, and Figure 3.

The same comparison in the selected elliptic-curve groups

Above: the publication's multiplicative notation. Below: additive notation with public keys and commitments in G₂, modified responses in G₁, and pairing results in G_T. In both columns, the challenge follows the commitment.

Original Okamoto: scalar response verified in G2 — The two protocols use the same public key and commitment notation. Only the modified protocol uses the transcript-bound point U and a pairing.

Modified Okamoto: group response verified with a pairing — The two protocols use the same public key and commitment notation. Only the modified protocol uses the transcript-bound point U and a pairing.

In the source figure, $\mathcal P$ is the prover and $\mathcal V$ the verifier. The secret key is $(a_1,a_2)$ , $A$ is the public key, $(x_1,x_2)$ is the ephemeral randomness, $X$ its commitment, and $c$ the verifier's challenge. Scalar arithmetic is modulo the prime group order $q$ .

The response equations below use multiplicative notation for the same asymmetric groups: $g_1,g_2\in G_2$ denote the displayed $Q_1,Q_2$ , $\hat g=U\in G_1$ , and $e:G_1\times G_2\to G_T$ . Multiplication and powers in the source groups represent point addition and scalar multiplication.

Original: scalar response

s_i=x_i+a_i\cdot c,\quad i=1,2

The verifier checks a group equation using the received $(s_1,s_2)$ :

g_1^{s_1}\cdot g_2^{s_2}=X\cdot A^c

For a nonzero challenge, a known $x_i$ exposes the corresponding secret:

a_i=(s_i-x_i)\cdot c^{-1}\pmod q

Modified: response in the group

\hat g=\mathcal H_{G_1}(\operatorname{ser}(X)\Vert\operatorname{ser}(c))

S_i=\hat g^{x_i+a_i\cdot c},\quad i=1,2

The verifier now checks a pairing equation:

e(S_1,g_1)\cdot e(S_2,g_2)= e(\hat g,X\cdot A^c)

The response no longer gives the verifier the scalars $(s_1,s_2)$ needed for that linear extraction. This is the purpose of lifting the response into the exponent.

Source notation. The original artwork retains the publication's symmetric pairing $\hat e:G\times G\to G_T$ . Its group-valued hash is denoted $\mathcal H$ in the paper. Throughout our explanations and executable asymmetric profile, the hash into $G_1$ is written $\mathcal H_{G_1}$ and the scalar-valued hash is written $\mathcal H$ . The code's $U$ corresponds to $\hat g$ in multiplicative notation. Concatenation always means encoded values, commitment first, challenge second.

From the paper to MCL WebAssembly

The executable example uses asymmetric pairing groups, with BLS12-381 selected initially. It writes elliptic-curve groups additively and keeps the target group multiplicative:

e:G_1\times G_2\to G_T

Keys and commitment: $Q_1,Q_2,A,X\in G_2$ . The figure's $g_1,g_2$ correspond to $Q_1,Q_2$ in the demo. $A=a_1\cdot Q_1+a_2\cdot Q_2,\quad X=x_1\cdot Q_1+x_2\cdot Q_2$ The two generators are derived with distinct labels; their discrete-logarithm relation must not be known.
Transcript-bound base: $U=\mathcal H_{G_1}(\operatorname{ser}(X)\Vert\operatorname{ser}(c))\in G_1$ Here $U$ replaces $\hat g$ . The code calls hashAndMapToG1 on the concatenated hexadecimal serializations, commitment first, challenge second. This is not a public hash-to-scalar multiplied by a fixed point.
Modified response: $S_i=(x_i+a_i\cdot c)\cdot U\in G_1,\quad i=1,2$ Exponentiation in the figure becomes scalar multiplication in $G_1$ ; $S_1,S_2$ are the transmitted points.
Verification: $e(S_1,Q_1)\cdot e(S_2,Q_2)=e(U,X+c\cdot A)$ Both sides are in $G_T$ . Every pairing takes a $G_1$ point first and a $G_2$ point second. The dot between the two pairings is multiplication in the target group.
Ordinary protocol: Ordinary Okamoto needs no pairing and can be instantiated in a suitable prime-order group, including $G_1$ or $G_2$ . Both variants have executable grids below: the regular protocol verifies scalar responses in G₂, and the modified protocol verifies G₁ response points using pairings.

Protected computation and scope of this demonstrator

The paper explicitly protects the long-term keys behind the exponentiation interfaces $\mathbf f_i(B)=B^{a_i}$ . It forms each response as $S_i=\hat g^{x_i}\cdot\mathbf f_i(\hat g^c)$ , without exporting the key or a scalar response from that protected component.

This browser demonstration computes and displays secret scalars for teaching. It does not implement an HSM or isolate those secrets from the browser. MCL's Fr values are scalars modulo $q$ ; the demo's random sampling has no explicit zero-rejection step, whereas the source artwork marks nonzero samples with $\mathbb Z_q^*$ .

The asymmetric equations above describe the actual executable arithmetic. They are not a claim that the paper's symmetric-group security reduction transfers unchanged to this implementation profile. See the publication for its security model and the MCL WebAssembly documentation for the library.

Protocol Steps

	01 Parameters
Pairing curve: 

MCL init...
P∈G1P\in G_1Q1,Q2∈G2Q_1,Q_2\in G_2

			   P:  
 
			   Q1:  

			   Q2:  

	02 Prover keyssk=(a1,a2)sk=(a_1,a_2)A=a1⋅Q1+a2⋅Q2A=a_1\cdot Q_1+a_2\cdot Q_2

			   sk1:  

			   sk2:  

			   pk:  

	03 Commitmentx1,x2∈Zqx_1,x_2\in\mathbb Z_qX=x1⋅Q1+x2⋅Q2X=x_1\cdot Q_1+x_2\cdot Q_2

				x1:  

				x2:  

				X:  

	04 Challengec∈Zqc\in\mathbb Z_q

				c:  

    05 ResponseU=ℋG1(ser(X)∥ser(c))U=\mathcal H_{G_1}(\mathrm{ser}(X)\Vert\mathrm{ser}(c))si=xi+ai⋅cs_i=x_i+a_i\cdot cSi=si⋅U,i=1,2S_i=s_i\cdot U,\quad i=1,2

			   U:  

			   s1:  

			   S1:  

			   s2:  

			   S2:  

    06 Verificatione1=e(S1,Q1)e_1=e(S_1,Q_1)e2=e(S2,Q2)e_2=e(S_2,Q_2)e3=e1⋅e2e_3=e_1\cdot e_2e4=e(U,X+c⋅A)e_4=e(U,X+c\cdot A)e3=e4e_3=e_4

			   e3:  

			   e4:  

			   Result:

Regular Okamoto Protocol Steps

01 ParametersQ1,Q2∈G2Q_1,Q_2\in G_2
Q1Q_1:
Q2Q_2:
02 Prover keyssk=(a1,a2)sk=(a_1,a_2)A=a1⋅Q1+a2⋅Q2A=a_1\cdot Q_1+a_2\cdot Q_2
a1a_1:
a2a_2:
AA:
03 Commitmentx1,x2∈Zqx_1,x_2\in\mathbb Z_qX=x1⋅Q1+x2⋅Q2X=x_1\cdot Q_1+x_2\cdot Q_2
x1x_1:
x2x_2:
XX:
04 Challengec∈Zqc\in\mathbb Z_q
cc:
05 Responsesi=xi+ai⋅cs_i=x_i+a_i\cdot ci=1,2i=1,2
s1s_1:
s2s_2:
06 VerificationL=s1⋅Q1+s2⋅Q2L=s_1\cdot Q_1+s_2\cdot Q_2R=X+c⋅AR=X+c\cdot AL=RL=R
LL:
RR:
Result: 

Original and modified: execution time

Mean milliseconds per run on the selected curve: 10 fresh transcripts after 3 warm-up runs. Both variants use the same pre-generated key; paired runs alternate their order. Includes fresh commitment and challenge randomness, response computation, and the complete verification equation. Modified verification recomputes $\mathcal H_{G_1}$ from the public transcript. Parameter generation, key generation, DOM updates and network transmission are excluded. These are local browser measurements, not security estimates or production benchmarks.

Stage	Original (ms)	Modified (ms)
Commitment
Challenge
Response
Verification
Total

Benchmark

op	msec
Fr::setByCSPRNG	0
pairing	0
millerLoop	0
finalExp	0
precomputedMillerLoop	0
G1::add	0
G1::dbl	0
G1::mul	0
G2::add	0
G2::dbl	0
G2::mul	0
hashAndMapToG1	0
hashAndMapToG2	0
Fr::add	0
Fr::mul	0
Fr::sqr	0
Fr::inv	0
GT::add	0
GT::mul	0
GT::sqr	0
GT::inv	0