rich1.0Joe Miyamoto Philips [ARCHIVE] (npub1rx…rdmna)https://yabu.me/npub1rxe6xx0tvp69u4ah8q7rl2v8yryawr9wv4zc2z2p59jupsdnnffslrdmnanjumphttps://yabu.me📅 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 are (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' = 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. P.S. I may have sent the same mail with a different address. Please ignore it. [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 compared to charging a fee by LN. https://spreadprivacy.com/duckduckgo-revenue-model/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210203/3ec104bc/attachment-0001.html>