Joe Miyamoto Philips [ARCHIVE] on Nostr: 📅 Original date posted:2021-02-05 📝 Original message: > If a malicious ...
📅 Original date posted:2021-02-05
📝 Original message:
> 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?
Yes, And in case of a trustful exchange with LN, the malicious server does
not even have to distinguish a user. The server can just choose one private
channel that is connected to itself and decides to be dishonest to it.
The victim has no way to prove that he did NOT receive a credential after
payment.
Thus I think making an exchange atomic is necessary in a commercial
application.
On Fri, Feb 5, 2021 at 9:00 PM <
lightning-dev-request at lists.linuxfoundation.org> wrote:
> Send Lightning-dev mailing list submissions to
> lightning-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> or, via email, send a message with subject or body 'help' to
> lightning-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> lightning-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Lightning-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Pay-for-Elgamal-decryption-key and its application to
> Anonymous Credentials (Lloyd Fournier)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 5 Feb 2021 11:05:58 +1100
> From: Lloyd Fournier <lloyd.fourn at gmail.com>
> To: ??? <joe.miyamoto at bitcoinbank.co.jp>
> Cc: "lightning-dev\\\\@lists.linuxfoundation.org"
> <lightning-dev at lists.linuxfoundation.org>
> Subject: Re: [Lightning-dev] Pay-for-Elgamal-decryption-key and its
> application to Anonymous Credentials
> Message-ID:
> <CAH5Bsr2b+1r=
> KOG+eQWBYNMZuwkaHZvsR1O+6bWaGqym6r9c6w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> ------------------------------
>
> End of Lightning-dev Digest, Vol 66, Issue 4
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210205/057d9dd8/attachment.html>;
📝 Original message:
> 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?
Yes, And in case of a trustful exchange with LN, the malicious server does
not even have to distinguish a user. The server can just choose one private
channel that is connected to itself and decides to be dishonest to it.
The victim has no way to prove that he did NOT receive a credential after
payment.
Thus I think making an exchange atomic is necessary in a commercial
application.
On Fri, Feb 5, 2021 at 9:00 PM <
lightning-dev-request at lists.linuxfoundation.org> wrote:
> Send Lightning-dev mailing list submissions to
> lightning-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> or, via email, send a message with subject or body 'help' to
> lightning-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> lightning-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Lightning-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Pay-for-Elgamal-decryption-key and its application to
> Anonymous Credentials (Lloyd Fournier)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 5 Feb 2021 11:05:58 +1100
> From: Lloyd Fournier <lloyd.fourn at gmail.com>
> To: ??? <joe.miyamoto at bitcoinbank.co.jp>
> Cc: "lightning-dev\\\\@lists.linuxfoundation.org"
> <lightning-dev at lists.linuxfoundation.org>
> Subject: Re: [Lightning-dev] Pay-for-Elgamal-decryption-key and its
> application to Anonymous Credentials
> Message-ID:
> <CAH5Bsr2b+1r=
> KOG+eQWBYNMZuwkaHZvsR1O+6bWaGqym6r9c6w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> ------------------------------
>
> End of Lightning-dev Digest, Vol 66, Issue 4
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210205/057d9dd8/attachment.html>;