What is the formal name -- and description -- of the problem of giving users access to a resource exactly once each while not requiring them to identify themselves?

In other words, to have a system that is able to give away access tokens to users as long as they have never obtained any before.

Assuming that users are able to perform cryptographic functions, and can be assumed to have personal certificates signed by the system, but which they do not want to reveal to the system in order to gain access.

Is there such a model? Is there such a well-described problem?

  • 2
    There is no such name, model, or description because what you are requesting is entirely impossible. There is quite literally no way to reliably do it. Commented Sep 23, 2019 at 22:07
  • 1
    There is no way to ensure contact1 <> contact2, they can start a new anonymous session and acquire a second token. Once you start locking down the distinct environment of the user (i.e. Cookies) you start de-anonymizing them. Commented Sep 23, 2019 at 22:23
  • I was thinking that maybe by using homomorphic signature scheme, the system can verify the a certificate which it had issued earlier to the user, while not being able to gain knowledge about the certificate itself, thus establishing the user as being a member of its userbase without individually identifying them. I was hoping that people with knowledge in cryptographic techniques can look into the question, that's why I originally posted it in the cryptography forum.
    – A. Gh.
    Commented Sep 25, 2019 at 20:23

2 Answers 2


There is no such model and no such problem. As long as users are not authenticated you cannot prevent multiple usage of your resources by the same user. Users can delete cookies, can change their IP, can change their browser, etc. If you require users to be authenticated then you can reduce the number of such cases, because some part of users can find it to difficult to create multiple accounts to your system. To assure each user has really a single account, or (more precisely) not too many accounts, you can use registration via mobile phone, or use credit card number in the registration process.

  • I'm not concerned with IPs and cookies here, and I didn't have them in mind as part of the system. But thanks.
    – A. Gh.
    Commented Sep 25, 2019 at 20:08
  • relevant: Signal's new group messaging, which will allow administrators to add and remove people from groups without a Signal server ever being aware of that group's members, required going further still. Signal partnered with Microsoft Research to invent a novel form of "anonymous credentials" that let a server gatekeep who belongs in a group, but without ever learning the members' identities. "It required coming up with some innovations in the world of cryptography," Marlinspike says. source: wired.com/story/signal-encrypted-messaging-features-mainstream
    – A. Gh.
    Commented Apr 14, 2020 at 22:09
  • @A.Gh.: I'm afraid you interpreted the wording at that web site incorrectly. Here is a link that explains what is understood by anonymous credentials: sciencedirect.com/topics/computer-science/anonymous-credential. Briefly: Each user is identified in advance. The CA does verify important attributes of the user, including his real name. By anonymous they mean that at the moment when some service requests user's certificate, user provides a transformed certificate, that contains no personal info and still shows that he was verified by CA.
    – mentallurg
    Commented Apr 15, 2020 at 0:20
  • @A.Gh.: To apply such a system you need 3 parties, not 2: User, your system that provides access, and CA (certification authority). CA will know all the users, will verify their real identities (like name, birth date, passport number, social security number or similar) and will make sure that the same person obtains only one certificate. Users will send to your server transformed certificate without disclosing their identity (who they really are). Despite this your server will know that certificate is valid...
    – mentallurg
    Commented Apr 15, 2020 at 0:29
  • @A.Gh.: ... But in your question you are talking only about 2 parties: 1) user; 2) the system, which performs both issuing certificates and checking access.
    – mentallurg
    Commented Apr 15, 2020 at 0:30

You have a system, X, where you want a user A to access X and never access it again. You can't know who A is, and A belongs to the set E with Everyone.

Even if you have the user act as a trustworthy user who will only attempt using their current system, as soon as they interact with your system they are no longer anonymous, as they belong to the previously empty set K of users who have interacted with your system. Why not just use a random access key and a

This problem can be shown mathematically quite easily by the way, where *f* is X(A) (i.e., X performing some operation on A) , f:E->K; any function acting on a member of E is constrained to fall in the set of K.

  • Thanks, but please also take a look at my comment on the main question above.
    – A. Gh.
    Commented Sep 25, 2019 at 20:25
  • So you haven't got an issue with separating between Everyone and Known users? Why not just distribute a single key to multiple users in K, the server checks that signature, and then you know that user belongs to K but not if they are K_1, K_2 etc
    – LTPCGO
    Commented Sep 26, 2019 at 5:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .