宮本丈 [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-03 📝 Original message: Hi all. I want to point ...
📅 Original date posted:2021-02-03
📝 Original message:
Hi all.
I want to point out another application of Discrete-Log selling on PTLC
lightning since I could not find anyone else mentioning it (in particular,
I could not find in the Nadav Kohen's list here. [1] )
The protocol may be obvious to most of the members here, but I believe its
application has some impact on the way people make anonymity-focused
applications with LN, so I want to have some feedback.
In short, by using ElGamal encryption, we can sell not only a discrete-log
but also an elliptic curve point which satisfies some requirements. This
includes KVAC [2] which is used for WabiSabi [3] and Signal app [4].
> disclaimer: I'm not a cryptography or math major, the following reasoning
might be wrong at the fundamental level. Please correct me if I'm wrong.
## Notations
* G ... Elliptic curve base point.
* H ... some additional NUMS
* x, X = x * G ... secret and public key
For ZKPoK, I will use Camenisch-Stadler like notation
PK{ (secret values) : statements about secret values to prove. }
e.g. For DLEQ proof. assume the verifier already have some points P_1, P_2
PK{ (x, y) : P_1 = x * G and P_2 = y * H and x = y }
# Protocols
## pay-for ElGamal decryption key
Quick recap, ElGamal encryption for message M (= m * G) is
(r * G, M + r * P)
where r is some blinding factor and P is a shared secret (P = p * G)
Imagine the Buyer knows some point (X_h = x * H), and he wants another
point (X_g = x * G).
The Seller knows x and he wants to sell the point X_g but he does NOT want
to reveal its discrete log x to the buyer.
(There is not much of a situation like this, but I will explain it later.)
In this case, the Seller can send its elgamal encryption and sell its
decryption key.
Seller:
* Generate ephemeral encryption key S = s * G
* Encrypt X_g with random blinding r ... (c1, c2) := (r * G, X_g + r * S)
* Send (c1, c2) and S to the Buyer.
* Also, send PK{(x, r, s) : c1 = r * G and c2 = x * G + r * S and X_h = x
* H }
Buyer
* Verifies the ZKPoK, he can be sure that the plaintext will be X_g that he
wants.
* Make a payment offer to the Seller with S.
Seller
* Receive the payment by revealing s
Buyer
* Decrypt the ciphertext by s to get the X_g ... (X_g := c2 - c1 * s)
## Pay for Keyed Verification Anonymous Credential. (KVAC)
We assume MAC_{GGM} scheme for the KVAC. [2]
* attributes encoded in the credential is m_1, ... m_n
* secret keys for the issuer=verifier is r, x_0, x_1, ... x_n
* Public params for the issuer is (C_x0 = x_0 * G + r * H), (X_1 = x_1 * G,
... X_n = x_n * G)
The credential is of the form (U, U') where U' = U * (x_0 + x_1 * m_1 + ...
+ x_n * m_n)
Issuer:
* get random point `U`
* compute U' = U * (x_0 + x_1 * m_1 + ... + x_n + m_n)
* sends U and ElGamal encryption of U' to the Buyer with blinding factor k
and ephemeral encryption key S.
* (c1, c2) = (k * G, U' + k * S)
* Also send ZKPoK to tell the ciphertext is for correct U'
* PK{(x_0, ... x_n, x_0, r, k, s) : U' = U * (x_0 + x_1 * m_1 + ... +
x_n * m_n) and C_x0 = G * x_0 + H * r and X_1 = x_1 * G and ... and X_n =
x_n * G and c1 = k * G and c2 = U' + k * S }
Then Buyer can buy s as the same as above.
# Why this matters
I believe that KVAC has great potential as a building block of anonymous
web apps.
Its MAC-based construction is more performant and easy to prove the
security compared to the similar system for the PKI based anonymous
credentials (e.g. U-Prove [5] and ACL [6]).
And it's a great fit for commercial purpose applications which do not have
to cooperate with other entities when defining the protocol. (Which is not
the case for an Attribute based credential system in general.)
The reason so far it has not been used widely is, IMHO, it's because there
is no way to charge its users anonymously. [7]
Another problem is Sybil attack. In general, the DoS protection is a great
concern for anonymous applications.
So we need users to commit something "scarce" to prevent it.
It is why Signal requires its users to register their telephone number
(Maybe I'm wrong about this, not sure).
(WabiSabi cleverly uses the user's UTXO as the scarce resource to mitigate
this problem.)
And of course, these problems get fixed by LN, if users have to pay to get
their service, the service does not have to ban the users by DoS-ing
anymore. So I think the LN-based payment and KVAC-based app fits very well.
Thus, if the service wants to grant some right to do something with their
server resource to users in an unlinkable fashion, then I believe
exchanging the credential in this way has a benefit.
Regards,
Miyamoto.
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002647.html
[2]: https://eprint.iacr.org/2013/516.pdf
[3]: https://github.com/zkSNACKs/WabiSabi
[4]: https://signal.org/blog/pdfs/signal_private_group_system.pdf
[5]: https://www.microsoft.com/en-us/research/project/u-prove/
[6]: https://core.ac.uk/download/pdf/193377167.pdf
[7]: DuckDuckGo has an interesting solution for this. But it is not a
general solution for all kinds of apps and I doubt how good it works.
https://spreadprivacy.com/duckduckgo-revenue-model/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210203/210db689/attachment.html>;
📝 Original message:
Hi all.
I want to point out another application of Discrete-Log selling on PTLC
lightning since I could not find anyone else mentioning it (in particular,
I could not find in the Nadav Kohen's list here. [1] )
The protocol may be obvious to most of the members here, but I believe its
application has some impact on the way people make anonymity-focused
applications with LN, so I want to have some feedback.
In short, by using ElGamal encryption, we can sell not only a discrete-log
but also an elliptic curve point which satisfies some requirements. This
includes KVAC [2] which is used for WabiSabi [3] and Signal app [4].
> disclaimer: I'm not a cryptography or math major, the following reasoning
might be wrong at the fundamental level. Please correct me if I'm wrong.
## Notations
* G ... Elliptic curve base point.
* H ... some additional NUMS
* x, X = x * G ... secret and public key
For ZKPoK, I will use Camenisch-Stadler like notation
PK{ (secret values) : statements about secret values to prove. }
e.g. For DLEQ proof. assume the verifier already have some points P_1, P_2
PK{ (x, y) : P_1 = x * G and P_2 = y * H and x = y }
# Protocols
## pay-for ElGamal decryption key
Quick recap, ElGamal encryption for message M (= m * G) is
(r * G, M + r * P)
where r is some blinding factor and P is a shared secret (P = p * G)
Imagine the Buyer knows some point (X_h = x * H), and he wants another
point (X_g = x * G).
The Seller knows x and he wants to sell the point X_g but he does NOT want
to reveal its discrete log x to the buyer.
(There is not much of a situation like this, but I will explain it later.)
In this case, the Seller can send its elgamal encryption and sell its
decryption key.
Seller:
* Generate ephemeral encryption key S = s * G
* Encrypt X_g with random blinding r ... (c1, c2) := (r * G, X_g + r * S)
* Send (c1, c2) and S to the Buyer.
* Also, send PK{(x, r, s) : c1 = r * G and c2 = x * G + r * S and X_h = x
* H }
Buyer
* Verifies the ZKPoK, he can be sure that the plaintext will be X_g that he
wants.
* Make a payment offer to the Seller with S.
Seller
* Receive the payment by revealing s
Buyer
* Decrypt the ciphertext by s to get the X_g ... (X_g := c2 - c1 * s)
## Pay for Keyed Verification Anonymous Credential. (KVAC)
We assume MAC_{GGM} scheme for the KVAC. [2]
* attributes encoded in the credential is m_1, ... m_n
* secret keys for the issuer=verifier is r, x_0, x_1, ... x_n
* Public params for the issuer is (C_x0 = x_0 * G + r * H), (X_1 = x_1 * G,
... X_n = x_n * G)
The credential is of the form (U, U') where U' = U * (x_0 + x_1 * m_1 + ...
+ x_n * m_n)
Issuer:
* get random point `U`
* compute U' = U * (x_0 + x_1 * m_1 + ... + x_n + m_n)
* sends U and ElGamal encryption of U' to the Buyer with blinding factor k
and ephemeral encryption key S.
* (c1, c2) = (k * G, U' + k * S)
* Also send ZKPoK to tell the ciphertext is for correct U'
* PK{(x_0, ... x_n, x_0, r, k, s) : U' = U * (x_0 + x_1 * m_1 + ... +
x_n * m_n) and C_x0 = G * x_0 + H * r and X_1 = x_1 * G and ... and X_n =
x_n * G and c1 = k * G and c2 = U' + k * S }
Then Buyer can buy s as the same as above.
# Why this matters
I believe that KVAC has great potential as a building block of anonymous
web apps.
Its MAC-based construction is more performant and easy to prove the
security compared to the similar system for the PKI based anonymous
credentials (e.g. U-Prove [5] and ACL [6]).
And it's a great fit for commercial purpose applications which do not have
to cooperate with other entities when defining the protocol. (Which is not
the case for an Attribute based credential system in general.)
The reason so far it has not been used widely is, IMHO, it's because there
is no way to charge its users anonymously. [7]
Another problem is Sybil attack. In general, the DoS protection is a great
concern for anonymous applications.
So we need users to commit something "scarce" to prevent it.
It is why Signal requires its users to register their telephone number
(Maybe I'm wrong about this, not sure).
(WabiSabi cleverly uses the user's UTXO as the scarce resource to mitigate
this problem.)
And of course, these problems get fixed by LN, if users have to pay to get
their service, the service does not have to ban the users by DoS-ing
anymore. So I think the LN-based payment and KVAC-based app fits very well.
Thus, if the service wants to grant some right to do something with their
server resource to users in an unlinkable fashion, then I believe
exchanging the credential in this way has a benefit.
Regards,
Miyamoto.
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002647.html
[2]: https://eprint.iacr.org/2013/516.pdf
[3]: https://github.com/zkSNACKs/WabiSabi
[4]: https://signal.org/blog/pdfs/signal_private_group_system.pdf
[5]: https://www.microsoft.com/en-us/research/project/u-prove/
[6]: https://core.ac.uk/download/pdf/193377167.pdf
[7]: DuckDuckGo has an interesting solution for this. But it is not a
general solution for all kinds of apps and I doubt how good it works.
https://spreadprivacy.com/duckduckgo-revenue-model/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210203/210db689/attachment.html>;