Hacker News Reader

Comment by O__________O | Hacker News Reader

I have seen it explained before, believe it was done using a combination of combination of differential privacy and zero knowledge proofs, but might wrong. Currently trying to find a detailed explanation of how to implement such a system using existing technology. In mean time, if anyone else is aware of such a system, please post a link.

EDIT: This appears to cover some aspects, still reviewing it and to confirm it covers all the system attributes I described:

https://crypto.stackexchange.com/questions/96232/zkp-prove-t...

View on HN

Hmm, I don't think that protocol as described would be sufficient for the government. What would prevent Alice (age 18) from sharing her signed age statement with her friend Charlie (age 17), who passes it to Bob to falsify his age? The government would not want underage users to collude with 18+ users to gain access to age-gated endpoints.

Agree, still trying to find full explanation, seen it described before. Aside from sharing the token, other issue is if the endpoint cached the token, it’s unique and could be cross-referenced to deanonymize the user if 3rd-party or government gained access to list of tokens an endpoint collected.

Obviously looking for example, but if you’re able to think of an additional issues that need to be accounted for, let me know.

Yep, that's another thing I was thinking of: if Alice uses the same token all the time for every endpoint, then the endpoints could trivially use that as a unique identifier to track Alice. Perhaps the government could create a service for Alice to create new age tokens whenever she wants.

Even then, if the government actively compelling endpoints to hand over their data is within the threat model, the government could inspect any cached temporary tokens to deanonymize the users. This could perhaps be mitigated with some way for users to irreversibly transform the temporary tokens given by the government, but I'm not sure if that's possible while retaining the ability for endpoints to verify the tokens.

Overall, though, the sharing problem seems to me to be the biggest issue by far with this scheme. What makes a user an individual human? In current implementations, their unique government ID (perhaps made illegal to falsify) is used for this. But I can't see how individual humans can be distinguished in a privacy-preserving way.

My memory was that the tokens enter a pool of tokens and that neither government or endpoint is able to trace which user used which token and they’re one-time use tokens, so users are unable to share them.

Never really gave system much thought at the time, since governments rarely want less data or to provide anonymous access — and average person does not care about anonymous access, in fact, in my experience they want everything logged. Same topic could easily be applied to numerous functions such as border crossings, but governments want to track who is crossing instead of just checking individual authorization to enter.

Unless it's a blinded token. In which case the endpoint cannot match the token that was issued to the token that was spent. They can only verify that the token is valid.

I first saw them used with Clouflare's Privacy Pass https://www.hcaptcha.com/privacy-pass, they've also been used with Google's trust token proposal.

Thanks, know I have looked at Privacy Pass before, not 100% sure after quick review of the related links if it covers the all system attributes I described; still looking it over.

For those interested, here’s the related paper covering it:

https://www.petsymposium.org/2018/files/papers/issue3/popets...

And yes, my understanding was tokens entered a pool of one-time tokens and neither the government or endpoint was able to cross reference them to a specific user.

Would these be susceptible to the issuing organization refusing to issue new tokens to some individual?

If you load link below and look for “Problem: Malleability” it say, “ It’s possible to create an arbitrary number of pairs of points that will be verified. The client can create these points by multiplying both T and sT by an arbitrary number a. If the client attempts to redeem aT and a(sT), the server will accept it. This effectively gives the client unlimited redemptions.”

Which to me might mean it might address if user is refused new tokens, it might not account for if the tokens are revoked or the authorizing entity ceased to exist, but the attribute was uniform, for example age.

https://privacypass.github.io/protocol/

All and all, at very least, appears to be an extensive and extendable standard, assuming those involved are reasonable and there’s no conflicting interests.

Another possible issue, for any scheme that uses government-issued temporary tokens (even blinded tokens) that have an expiration date: the government could stop issuing tokens to a user at any time, preventing them from accessing any gated sites after their current tokens expire.

Agree, more to the point, once some attributes are verified, for example age, it shouldn’t require government to reverify. That said, some attributes should require if needed real-time verification, for example if an individual is legally allowed to drive, enter a country, etc.

Wouldn't caching verification data require the endpoints to hold user sessions? Thus, if the government withheld verification services for a user, wouldn't it prevent that user from creating new independent sessions on their current endpoints, as well as preventing that user from verifying on new endpoints?

Not 100% sure understand you, but believe this comment might address your question:

https://news.ycombinator.com/item?id=33133749

Ideally, endpoints would not even know the specific authentication provider, but that the authentication came from a authentication service that’s authorized to confirm a given identity and related attributes; for example, being over X age is a binary attribute and numerous entities should be able to authenticate that and it be honored by a jurisdiction similar to how passports are uniform.

Reply on news.ycombinator.com