2

Following up this question

There are 4 parties:

  • Alice, who needs to prove a posession of some statement $m$, unique to her, say a street address, which is basically a string of some predefined format, to
  • Bob, who consumes the proof.
  • an Oracle, who "helps" Alice to prove $m$ by performing some external checks and signing a tuple of ("Alice", $m$, timestamp)
  • A good Samaritan Sam, who wants to help Alice prove statement $m$ because he actually owns it

Normal protocol flow is as follows:

  • Alice says "I can prove some unique info about me" to Bob.
  • Bob composes $m$ and asks Alice to prove it.
  • Alice asks Oracle(s) to help her prove $m$.
  • Oracle(s) do their magic and issue a signed tuple ("Alice", $m$, timestamp) to some online storage for using later.
  • Alice shares the ID of the signed tuple to Bob.
  • Bob fetches the tuple from online storage, validates Oracle's signature, timestamp and rewards Alice with whatever they agreed on.

Now, for the attacks:

If Alice does not posess $m$ she might want to ask Sam to pretend he is Alice and pass the Oracle check for her. She might share her "Alice" identity (we'll define it later) to him.
We want to prevent this or to at least make Alice's and Sam's life very difficult in case they collude.

One way of achieving this is to track the public key that signed $m$ each time and perform penalty if it changes.

So, we ask Alice to sign each statement with a special ephemeral key before sending it to an Oracle. This ephemeral key has to be derived from her master secret using KDF(master_secret,$hash(m))$ which she can prove to Bob using some sort of ZKP. So the only way for Alice to use Sam would be to share her master secret with him.

It also allows Alice to sign different statements without being doxxed by figuring out that $m1, m2, m3$ were proved by the same person

So, the question is, is there a simpler way of achieving these goals than doing complex ZKP for KDFs?

knaccc
  • 4,880
  • 1
  • 18
  • 33
John dow
  • 149
  • 8

1 Answers1

2

Alice has a master private key scalar $a$, with corresponding public key $A=aG$. $G$ is a well-known base point on the curve.

Alice deterministically creates a new identity associated with a particular message $m$. She calculates the private key $b = HKDF_s(a, m)$, where $\operatorname{HKDF_s}$ means to use HKDF to derive a scalar result. Alice calculates the corresponding public key $B=bG$.

Alice encrypts her master private key with a uniformly random scalar $k$, as $a'=a+k$. She calculates $K=kG$.

Alice discloses $A$, $B$, $K$ and $a'$ to the Oracle. The Oracle verifies that $a'G\overset{?}{=} A+K$.

The Oracle signs the tuple ($B$, $K$, $a'$, $m$, timestamp) and stores that signed tuple as part of the public record. The Oracle does not disclose $A$ publicly. This signed tuple asserts that the Oracle allows the public key $B$ to be associated with $m$.

From now on, when signing messages associated with this tuple, Alice must sign twice - once with $B$ and once with $K$.

This proves that Alice knows both $b$ and $k$.

Alice cannot disclose $b$ and $k$ to Sam, because Sam would be able to recover $a$ as $a = a'-k$.

Note: scalar addition and subtraction are modulo the order of group generated by the base point.

knaccc
  • 4,880
  • 1
  • 18
  • 33