0

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?

|improve this question

migrated from crypto.stackexchange.com Sep 23 at 21:03

This question came from our site for software developers, mathematicians and others interested in cryptography.

  • 1
    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. – Conor Mancone Sep 23 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. – Andrew Russell Sep 23 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. Sep 25 at 20:23
0

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.

|improve this answer
  • 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. Sep 25 at 20:08
0

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.

|improve this answer
  • Thanks, but please also take a look at my comment on the main question above. – A. Gh. Sep 25 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 Sep 26 at 5:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.