Modified Schnorr 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 Schnorr-like Identification Scheme Resistant to Malicious Subliminal Setting of Ephemeral Secret. Cryptographic operations run locally using MCL WebAssembly.

Original and modified Schnorr

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 Schnorr 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 SECITC 2016, Section 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 Schnorr: 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 Schnorr: 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$ , $A$ is the public key, $x$ 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\in G_2$ denote the displayed $Q$ , $\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=x+a\cdot c

The verifier checks a group equation using the received $s$ :

g^s=X\cdot A^c

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

a=(s-x)\cdot c^{-1}\pmod q

Modified: response in the group

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

S=\hat g^{x+a\cdot c}

The verifier now checks a pairing equation:

e(S,g)= e(\hat g,X\cdot A^c)

The response no longer gives the verifier the scalar $s$ 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,A,X\in G_2$ . The figure's $g$ corresponds to $Q$ in the demo. $A=a\cdot Q,\quad X=x\cdot Q$ The parameter $P\in G_1$ shown in the parameter panel is not the response base.
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=(x+a\cdot c)\cdot U\in G_1$ Exponentiation in the figure becomes scalar multiplication in $G_1$ ; $S$ is the transmitted point.
Verification: $e(S,Q)=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.
Ordinary protocol: Ordinary Schnorr needs no pairing and can be instantiated in a suitable prime-order group, including $G_1$ or $G_2$ . The separate Regular Schnorr grid on this page uses $G_2$ and checks $s\cdot Q=X+c\cdot A$ .

Protected computation and scope of this demonstrator

The paper considers protected long-term keys alongside ephemeral randomness that may be exposed or adversarially set. Its security argument uses the stated group assumptions and random-oracle model, not merely the appearance of a group-valued response.

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.

Mod-Schnorr Protocol Steps

	01 Parameters
Pairing curve: 

MCL init...
P∈G1, Q∈G2P\in G_1,\ Q\in G_2

			   P:  
 
			   Q:  

	02 Prover keyssk=ask=apk=A=a⋅Qpk=A=a\cdot Q

			   sk:  

			   pk:  

	03 Commitmentx∈Zqx\in\mathbb Z_qX=x⋅QX=x\cdot Q

				x:  

				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))s=x+a⋅cs=x+a\cdot cS=s⋅US=s\cdot U

			   s:  

			   U:  

			   S:  

    06 Verificatione(S,Q)=e(U,X+c⋅A)e(S,Q)=e(U,X+c\cdot A)

			   e1:  

			   e2:  

			   Result:

Regular Schnorr Protocol Steps

	01 ParametersQ∈G2Q\in G_2

			   Q:  

	02 Prover keyssk=ask=apk=A=a⋅Qpk=A=a\cdot Q

			   sk:  

			   pk:  

	03 Commitmentx∈Zqx\in\mathbb Z_qX=x⋅QX=x\cdot Q

				x:  

				X:  

	04 Challengec∈Zqc\in\mathbb Z_q

				c:  

    05 Responses=x+a⋅cs=x+a\cdot c

			   s:  

    06 Verifications⋅Q=X+c⋅As\cdot Q=X+c\cdot A

			   L:  

			   R:  

			   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