Open akakou opened 1 year ago
In many cases, GM limits them on GM's website using IP addresses, SMS authentication, or other schemes.
If this proposal is delegating to a third party to do rate limiting of key generation (using some mechanism not described within), what value does this proposal have over Privacy Pass?
@michaelficarra
Thank you for your question.
As you said, EPID and Privacy Pass are similar but have different features. The most essential difference is the rate limit and revocability. As far as I know, Privacy Pass mainly ensures the access rate. However, Privacy Pass does not provide the revocation method. On the other hand, EPID cannot be used for rate-limit, but it has revocation capability.
The proposal's main focus is on the revocability of the EPID.
(To be precise, the service can revoke users using a Privacy Pass if the TTP provides only one ticket to a user. However, it causes significant privacy issues as same as other identifiers.)
Moreover, their security assumptions are different. Specifically, Privacy Pass has the risk of a timing collusion attack; however, EPID does not. Instead, EPID has risks caused by malicious revocation lists, so that needs some privacy measures, as you know (detail is in Q&A 4).
I found that performance EPID is a difficult challenge, and it has the potential risk of occurring the DoS attack as explained in this.
Hopefully, there is a good solution...
Therefore, I will research to address this problem now...
I found this!
SNARKBlock: Federated Anonymous Blocklisting from Hidden Common Input Aggregate Proofs
@akakou That looks very interesting! Are you going to present this result to the group?
@michaelficarra Thank you comment :pray:
I would like to do that. But I have not understood all of that yet. So I would like some time to understand the article.
This proposal achieves privacy-friendly revocation (i.e., ban). In particular, it makes a web servicer(i.e., web server) capable of blocking users who have previously abused them; however, it has no risk for privacy violations.
Background
As is well known, malicious actions (e.g., cheating in games) are a significant problem, including in Web applications. To solve these problems, revoking malicious users is an excellent function to reduce fraud.
Currently, the most straightforward way of revocation is to use the user identifier strongly coupled with the user's identity. (e.g., National ID, Phone number, IP address(?))
However, they have privacy concerns, especially user tracking by services.
Idea
This idea is for Web APIs to provide a privacy-enhanced revocation method.
It mainly consists of a cryptographic anonymous blocklisting protocol such as EPID(Enhanced Privacy ID). EPID is a signature scheme that ensures user anonymity but revocability, too. Using EPID, services can revoke users while not being able to track users. Specifically, EPID has the signature-based revocation ability that allows services to revoke users using their signature (without using the user's information).
This API provides signing and part of joining(i.e., Key generation and Credential saving) in EPID and some security/privacy measures.
Note that although EPID assumes a third-party entity (GM: Group Manager) limits the number of user's secret keys, the implementation to limit it is out of scope in this API. In other words, the proposal entrusts a defining identification method to the GM (like Secure Payment Confirmation API). In many cases, GM limits them on GM's website using IP addresses, SMS authentication, or other schemes.
Moreover, the browser and extension developers can be and add the GM in other ways.
Base ideas
Privacy-Enhanced Revocation(AFCG meetings)
Web hardware revocation API
19
References
EPID: Enhanced Privacy ID
Secure Payment Confirmation API