Łukasz Krzywiecki

Hierarchical Ring Signatures with Hidden Signature Functionality

Functional proof-of-concept for the TrustCom 2025 paper. The blockchain layer is represented as an append-only verifier order; the demo focuses on nodes of the form $(m, σ, {pk}_{n}, Y)$ , where $Y \subset L \cup N$ .

DOI Papers D3 dependency tree MCL WASM loading

Repository hierarchy

Click any signature node to expand or collapse dependencies.

Command clickselect Y

Shift clicksigner path

Option clickverify node

Node inspector

Hover a circle to see the node message and its children.

Preparing repository...

Add hierarchical signature

Eligible signer from Y Select Y to show eligible signers. Hidden signature Hidden functionality Message Hidden message

Ring set Y = L union N. Each person has one certified leaf key in L. Select in the hierarchy with Command-click, or tick entries below.

Selected signature

Repository

Markdown-style scheme notes + MathML

Scheme specification implemented by this page

The proof-of-concept follows the hierarchical ring signature layer from the TrustCom 2025 paper and the earlier HRS line of work. The browser demo does not emulate a blockchain consensus protocol; it treats the repository as an append-only, verified order of nodes.

Executable MCL model

### 1. Public parameters and state

The scheme is defined over a cyclic group of prime order. In the paper this is written multiplicatively as $G = ⟨ g ⟩$ with public keys $pk = g^{sk}$ . The browser implementation uses MCL additively over G1, where the fixed base point is denoted by $P$ in the notes below.

R = {L, N, S}

$H$ denotes the domain-separated random-oracle calls; it is not the repository state.
$L$ is the set of certified external public keys.
$N$ is the set of node public keys created by previous HRS signatures.
$S$ is the append-only set of verified nodes.
Each public node is stored as $(m, σ, {pk}_{n}, Y)$ . Here $σ$ is a compound HRS signature: $σ = (s, {(R_{i}, {cert}_{i}, h_{i})}_{{pk}_{i} \in Y})$ . The demo also keeps an administrative signer witness so that the visualization can reveal the hidden path on demand.

### 2. Dependency set and tree condition

A new signature chooses a dependency set $Y \subset L \cup N$ . This set may contain certified user keys and previously generated node keys. The tree condition prevents comparable ancestry inside the same ring: one selected predecessor may not already contain another selected predecessor in its history.

T (Y) = 1 \Leftrightarrow \neg \exists {pk}_{a}, {pk}_{b} \in Y : {pk}_{a} ≺ {pk}_{b}

The demo enforces this rule before adding a node: selected bases may be siblings or independent roots, but one selected base cannot already contain another selected base in its history.

ParGen(1^lambda) system setup

Generate $(p, q, g, G)$ with prime order $q$ , where $G = ⟨ g ⟩$ .
Select domain-separated hash functions modeled as random oracles for Schnorr challenges, HRS challenges, and hidden openings.
Publish the public parameters. The browser version fixes these parameters through MCL WebAssembly over BLS12-381 G1.

KeyGen() ordinary and node keys

Sample $sk \leftarrow Z_{q}$ .
Compute the public key $pk = g^{sk}$ .
For an HRS node, the freshly generated key pair $({sk}_{n}, {pk}_{n})$ has a special certification role. The secret key ${sk}_{n}$ signs every ring commitment $R_{i}$ , producing a certificate ${cert}_{i}$ . The public key ${pk}_{n}$ is then checked by the verifier against all those certificates.

Schnorr.Cert(R_i, skn) certifying each ring commitment

Sample the Schnorr randomness $u$ and compute $U = g^{u}$ .
Set the certified statement to $x_{i} = certify || R_{i}$ . This statement is the ring commitment produced from the committed randomness of the ring-signature equation.
Hash the statement, Schnorr commitment, and node public key to obtain $e = H_{Schnorr} (x_{i}, U, {pk}_{n})$ .
Return the certificate as a Schnorr signature $σ_{i}^{cert} = (U, z)$ , stored in the node as ${cert}_{i} = σ_{i}^{cert}$ with $z = u + e \cdot {sk}_{n}$ .
Verification checks $g^{z} = U \cdot {pk}_{n}^{e}$ . Thus the fresh node key certifies that each commitment $R_{i}$ belongs to the node being created.

NRSign(m, sk_j, Y) hierarchical ring signature and node certification

Create a fresh node key $({sk}_{n}, {pk}_{n})$ . This key pair is not one of the anonymous signer keys in $Y$ ; it is the new node key that will certify the ring commitments and become the public key of the newly appended node.
For every non-signer key ${pk}_{i} \in Y$ , sample $r_{i}$ , set $R_{i} = g^{r_{i}}$ , certify $R_{i}$ with ${sk}_{n}$ by computing ${cert}_{i} = Schnorr.Cert (R_{i}, {sk}_{n})$ , and compute $h_{i} = H_{HRS} (m, R_{i}, {cert}_{i})$ .
For the actual signer ${pk}_{j}$ , sample $r_{j}$ and close the ring equation by defining $R_{j} = g^{r_{j}} \cdot \prod_{i \neq j}^{} {pk}_{i}^{- h_{i}}$
Certify $R_{j}$ in the same way, compute $h_{j} = H_{HRS} (m, R_{j}, {cert}_{j})$ , and output $s = \sum_{i \neq j}^{} r_{i} + r_{j} + {sk}_{j} \cdot h_{j}$
Store the node $(m, σ, {pk}_{n}, Y)$ , where $σ = (s, {(R_{i}, {cert}_{i}, h_{i})}_{{pk}_{i} \in Y})$ , and append ${pk}_{n}$ to $N$ . The dependency is deliberately two-way in meaning: ${sk}_{n}$ certifies the randomness commitments $R_{i}$ , while the accepted HRS equation binds ${pk}_{n}$ to the message $m$ and to the selected anonymity set $Y$ .

NRVerify(m, sigma, pkn, Y) node verification

Verify every Schnorr certificate ${cert}_{i}$ over the corresponding commitment $R_{i}$ using ${pk}_{n}$ . This is the local certification layer inside the node signature.
Recompute every challenge $h_{i} = H_{HRS} (m, R_{i}, {cert}_{i})$ . Since ${cert}_{i}$ is hashed into $h_{i}$ , the ring equation binds the new public node key ${pk}_{n}$ to the ring signature.
Accept exactly when the ring equation holds: $g^{s} = \prod_{{pk}_{i} \in Y}^{} (R_{i} \cdot {pk}_{i}^{h_{i}})$

NRASign / NRAVerify hidden signature functionality

For a selected non-signer component $k$ , replace the random value by a deterministic opening derived from a hidden message and context: $r_{k} = H_{open} (H_{m} ({\tilde{m}}_{k}) || H_{c} ({\tilde{c}}_{k}))$
The hidden message ${\tilde{m}}_{k}$ is a secondary payload carried by a non-signer component of the ring. It can be a short statement, a reference to an external fact, or even an already produced external signature. In the last case the HRS node acts as a public carrier for a hidden signature channel, while the visible HRS signature remains an ordinary node signature on $m$ .
Stealth comes from the replacement of ordinary non-signer randomness by a hash-derived scalar. With $H$ modeled as a random oracle, the value $r_{k} = H_{open} (H_{m} ({\tilde{m}}_{k}) || H_{c} ({\tilde{c}}_{k}))$ is computationally indistinguishable from a fresh random scalar in $Z_{q}$ . Thus the public commitment $R_{k} = g^{r_{k}}$ looks like an ordinary random commitment unless the verifier already knows both the hidden message and the salt.
The salt ${\tilde{c}}_{k}$ is not cosmetic. It gives the hidden input enough entropy and prevents practical hash-inversion or dictionary attempts against short hidden messages.
The public node still verifies as an ordinary HRS node, so the extra payload is not visible to ordinary verifiers.
In this page, the salt field represents the hidden context, and the scalar opening is produced by hiddenOpeningScalar applied to the mathematical pair $(\tilde{m}, \tilde{c})$ and implemented as $H_{open} (H_{m} (\tilde{m}) || H_{c} (\tilde{c}))$ with explicit domain separation.
A hidden verifier accepts the extra message after checking that $R_{k} = g^{r_{k}}$ is one of the certified ring commitments. Public NRVerify does not need the hidden message.

### 3. Exact equation executed in the browser

MCL exposes elliptic-curve groups additively. Therefore the code computes the additive form of the paper equation:

s \cdot P = \sum_{{pk}_{i} \in Y}^{} (R_{i} + h_{i} \cdot {PK}_{i})

The map is direct: $g^{a} \mapsto a \cdot P$ ; a public key ${pk}_{i}$ becomes the MCL point ${PK}_{i}$ ; products become sums; inverse exponents become scalar negation. This avoids using $Y$ both for the ring set and for an individual public-key point.

### 4. How the interface maps to the construction

leaf.secretKey and leaf.publicKey model certified keys from $L$ .
record.nodeSecretKey and record.nodePublicKey model fresh HRS node keys $({sk}_{n}, {pk}_{n})$ whose public keys are added to $N$ . In the demo, the node secret remains controlled by the same signer/owner who used the signing key. It may be stored, or derived deterministically, for example as ${sk}_{n} \leftarrow H_{key} ({sk}_{owner} ∥ {id}_{n})$ .
record.dependencies is the selected ring set $Y$ .
record.signature.ring stores the certified commitments $(R_{i}, {cert}_{i}, h_{i})$ . In code, ${cert}_{i}$ appears as entry.certificate and is a Schnorr certificate under the fresh node key ${pk}_{n}$ .
record.signerKeyId is an administrative witness used only by the simulator; it identifies which secret key was used and therefore which signer/owner color is shown. It is not serialized into the public HRS signature or the public digest.
verifyNodeSignature(record) checks the public Schnorr certificates and additive HRS equation.
verifyHiddenPayloads(record) checks the optional hidden openings, while verifyRepository() also checks the tree condition, public digest chain, dependency order, and Y entries.

### 5. Reading the tree as a repository

White dashed leaves are certified public keys from $L$ . Red nodes are HRS signatures whose public node keys have been appended to $N$ . Expanding a node reveals the selected dependency set $Y$ ; collapsing it hides already verified history in the same way an on-chain verifier may rely on previously accepted repository nodes.

The essential point is that a later signature can use earlier signatures as bases. This creates a hierarchical order: older signatures certify roots for later signatures, and the append-only order gives the structure a timestamp-like interpretation without showing which selected key was the actual signer.

Verified references used by this specification

Sources: papers.html, the local DBLP export, and the bibliography of the TrustCom 2025 HRS manuscript.

Łukasz Krzywiecki, Witold Karaś, Adam Niezgoda, Karol Niczyj. Hierarchical Ring Signatures with Hidden Signature Functionality over Blockchain Infrastructure. TrustCom 2025: 2010-2015. DOI: 10.1109/Trustcom66490.2025.00233.
Łukasz Krzywiecki, Mirosław Kutyłowski, Rafał Rothenberger, Bartosz Drzazga. Hierarchical Ring Signatures Immune to Randomness Injection Attacks. CSCML 2021: 171-186. DOI: 10.1007/978-3-030-78086-9_13.
Łukasz Krzywiecki, Malgorzata Sulkowska, Filip Zagórski. Hierarchical Ring Signatures Revisited - Unconditionally and Perfectly Anonymous Schnorr Version. SPACE 2015: 329-346. DOI: 10.1007/978-3-319-24126-5_19.
Łukasz Krzywiecki, Mirosław Kutyłowski, Anna Lauks. Hierarchical Ring Signatures. Slides presented at Western European Workshop on Research in Cryptology, 2009.
Marek Klonowski, Łukasz Krzywiecki, Mirosław Kutyłowski, Anna Lauks. Step-Out Ring Signatures. MFCS 2008: 431-442. DOI: 10.1007/978-3-540-85238-4_35.
Ronald L. Rivest, Adi Shamir, Yael Tauman. How to Leak a Secret. ASIACRYPT 2001: 552-565.
Javier Herranz, Germán Sáez. Forking Lemmas for Ring Signature Schemes. INDOCRYPT 2003: 266-279. DOI: 10.1007/978-3-540-24582-7_20.
Claus-Peter Schnorr. Efficient Signature Generation by Smart Cards. Journal of Cryptology 4: 161-174, 1991.