📅 Original date posted:2021-02-04
📝 Original message:
Hi Miyamoto,
Very interesting idea :)
Usually when dealing with anonymous credentials you are necessarily dealing
with a trusted third party so it's fine to just make a normal payment and
then receive the credential after successfully paying.
But I see the advantage of your idea. If a malicious credential server is
able to identify you somehow at the point of payment then they might want
to selectively steal your money while being honest with everyone else.
In your scheme, if you pay you get the credential and then since it is
anonymous it can't be distinguished from others when you go to claim
whatever it entails.
Is this the idea?
Cheers,
LL
On Thu, Feb 4, 2021 at 1:04 PM 宮本丈 via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
>
> 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/
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210205/8001a145/attachment.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:01:55
in reply to nevent1q…drhd
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:01:55Event JSON
{
"id": "b6a4f2bba93a680154f70712b80fc87694213caf918bb0a5b8c20a6a8b0a0915",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315715,
"kind": 1,
"tags": [
[
"e",
"cc78c82d6043d9fbfd30a76184bed9e3b5ae0ad86f5f50521850e3a11ca245bb",
"",
"root"
],
[
"e",
"aa4983430948d35fa29a05730718c6dd4c3df38851bc54f08b6e8908e30371c7",
"",
"reply"
],
[
"p",
"f4b25b0da16cce946b4c1863926f98c153846ea1374ec6cd52b00d9bf7c2ef17"
]
],
"content": "📅 Original date posted:2021-02-04\n📝 Original message:\nHi Miyamoto,\n\nVery interesting idea :)\nUsually when dealing with anonymous credentials you are necessarily dealing\nwith a trusted third party so it's fine to just make a normal payment and\nthen receive the credential after successfully paying.\nBut I see the advantage of your idea. If a malicious credential server is\nable to identify you somehow at the point of payment then they might want\nto selectively steal your money while being honest with everyone else.\nIn your scheme, if you pay you get the credential and then since it is\nanonymous it can't be distinguished from others when you go to claim\nwhatever it entails.\nIs this the idea?\n\nCheers,\n\nLL\n\nOn Thu, Feb 4, 2021 at 1:04 PM 宮本丈 via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e Hi all.\n\u003e\n\u003e I want to point out another application of Discrete-Log selling on PTLC\n\u003e lightning since I could not find anyone else mentioning it (in particular,\n\u003e I could not find in the Nadav Kohen's list here. [1] )\n\u003e\n\u003e The protocol may be obvious to most of the members here, but I believe its\n\u003e application has some impact on the way people make anonymity-focused\n\u003e applications with LN, so I want to have some feedback.\n\u003e\n\u003e In short, by using ElGamal encryption, we can sell not only a discrete-log\n\u003e but also an elliptic curve point which satisfies some requirements. This\n\u003e includes KVAC [2] which is used for WabiSabi [3] and Signal app [4].\n\u003e\n\u003e \u003e disclaimer: I'm not a cryptography or math major, the following\n\u003e reasoning might be wrong at the fundamental level. Please correct me if I'm\n\u003e wrong.\n\u003e\n\u003e ## Notations\n\u003e\n\u003e * G ... Elliptic curve base point.\n\u003e * H ... some additional NUMS\n\u003e * x, X = x * G ... secret and public key\n\u003e\n\u003e For ZKPoK, I will use Camenisch-Stadler like notation\n\u003e PK{ (secret values) : statements about secret values to prove. }\n\u003e e.g. For DLEQ proof. assume the verifier already have some points P_1, P_2\n\u003e PK{ (x, y) : P_1 = x * G and P_2 = y * H and x = y }\n\u003e\n\u003e # Protocols\n\u003e\n\u003e ## pay-for ElGamal decryption key\n\u003e\n\u003e Quick recap, ElGamal encryption for message M (= m * G) is\n\u003e (r * G, M + r * P)\n\u003e where r is some blinding factor and P is a shared secret (P = p * G)\n\u003e\n\u003e Imagine the Buyer knows some point (X_h = x * H), and he wants another\n\u003e point (X_g = x * G).\n\u003e The Seller knows x and he wants to sell the point X_g but he does NOT want\n\u003e to reveal its discrete log x to the buyer.\n\u003e (There is not much of a situation like this, but I will explain it later.)\n\u003e\n\u003e In this case, the Seller can send its elgamal encryption and sell its\n\u003e decryption key.\n\u003e Seller:\n\u003e * Generate ephemeral encryption key S = s * G\n\u003e * Encrypt X_g with random blinding r ... (c1, c2) := (r * G, X_g + r * S)\n\u003e * Send (c1, c2) and S to the Buyer.\n\u003e * Also, send PK{(x, r, s) : c1 = r * G and c2 = x * G + r * S and X_h = x\n\u003e * H }\n\u003e\n\u003e Buyer\n\u003e * Verifies the ZKPoK, he can be sure that the plaintext will be X_g that\n\u003e he wants.\n\u003e * Make a payment offer to the Seller with S.\n\u003e\n\u003e Seller\n\u003e * Receive the payment by revealing s\n\u003e\n\u003e Buyer\n\u003e * Decrypt the ciphertext by s to get the X_g ... (X_g := c2 - c1 * s)\n\u003e\n\u003e ## Pay for Keyed Verification Anonymous Credential. (KVAC)\n\u003e\n\u003e We assume MAC_{GGM} scheme for the KVAC. [2]\n\u003e\n\u003e * attributes encoded in the credential is m_1, ... m_n\n\u003e * secret keys for the issuer=verifier is r, x_0, x_1, ... x_n\n\u003e * Public params for the issuer is (C_x0 = x_0 * G + r * H), (X_1 = x_1 *\n\u003e G, ... X_n = x_n * G)\n\u003e\n\u003e The credential is of the form (U, U') where U' = U * (x_0 + x_1 * m_1 +\n\u003e ... + x_n * m_n)\n\u003e\n\u003e Issuer:\n\u003e * get random point `U`\n\u003e * compute U' = U * (x_0 + x_1 * m_1 + ... + x_n + m_n)\n\u003e * sends U and ElGamal encryption of U' to the Buyer with blinding factor k\n\u003e and ephemeral encryption key S.\n\u003e * (c1, c2) = (k * G, U' + k * S)\n\u003e * Also send ZKPoK to tell the ciphertext is for correct U'\n\u003e * PK{(x_0, ... x_n, x_0, r, k, s) : U' = U * (x_0 + x_1 * m_1 + ... +\n\u003e x_n * m_n) and C_x0 = G * x_0 + H * r and X_1 = x_1 * G and ... and X_n =\n\u003e x_n * G and c1 = k * G and c2 = U' + k * S }\n\u003e\n\u003e Then Buyer can buy s as the same as above.\n\u003e\n\u003e # Why this matters\n\u003e\n\u003e I believe that KVAC has great potential as a building block of anonymous\n\u003e web apps.\n\u003e Its MAC-based construction is more performant and easy to prove the\n\u003e security compared to the similar system for the PKI based anonymous\n\u003e credentials (e.g. U-Prove [5] and ACL [6]).\n\u003e And it's a great fit for commercial purpose applications which do not have\n\u003e to cooperate with other entities when defining the protocol. (Which is not\n\u003e the case for an Attribute based credential system in general.)\n\u003e\n\u003e The reason so far it has not been used widely is, IMHO, it's because there\n\u003e is no way to charge its users anonymously. [7]\n\u003e Another problem is Sybil attack. In general, the DoS protection is a great\n\u003e concern for anonymous applications.\n\u003e So we need users to commit something \"scarce\" to prevent it.\n\u003e It is why Signal requires its users to register their telephone number\n\u003e (Maybe I'm wrong about this, not sure).\n\u003e (WabiSabi cleverly uses the user's UTXO as the scarce resource to mitigate\n\u003e this problem.)\n\u003e\n\u003e And of course, these problems get fixed by LN, if users have to pay to get\n\u003e their service, the service does not have to ban the users by DoS-ing\n\u003e anymore. So I think the LN-based payment and KVAC-based app fits very well.\n\u003e\n\u003e Thus, if the service wants to grant some right to do something with their\n\u003e server resource to users in an unlinkable fashion, then I believe\n\u003e exchanging the credential in this way has a benefit.\n\u003e\n\u003e\n\u003e Regards,\n\u003e\n\u003e Miyamoto.\n\u003e\n\u003e\n\u003e [1]:\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002647.html\n\u003e [2]: https://eprint.iacr.org/2013/516.pdf\n\u003e [3]: https://github.com/zkSNACKs/WabiSabi\n\u003e [4]: https://signal.org/blog/pdfs/signal_private_group_system.pdf\n\u003e [5]: https://www.microsoft.com/en-us/research/project/u-prove/\n\u003e [6]: https://core.ac.uk/download/pdf/193377167.pdf\n\u003e [7]: DuckDuckGo has an interesting solution for this. But it is not a\n\u003e general solution for all kinds of apps and I doubt how good it works.\n\u003e https://spreadprivacy.com/duckduckgo-revenue-model/\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210205/8001a145/attachment.html\u003e",
"sig": "418f266ffcb3bc8040a4fe19b880e37763226a76875318321c0ef8976754547ba1d8d07d38b7077376321e0460406c70c8954d0282d49f94098e9cb6faa8f01d"
}