Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-04 📝 Original message: Hi Miyamoto, Very ...
📅 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>;
📝 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>;