Comment by cobertos
1 year ago
What's to stop someone on the Kagi side from just adding a new column to the token table that has the user (with their SessionCookie) who generated the token next to it? I don't see how this can't be trivially connected to the original token generator.
Implementor here. During the Privacy Pass "issuance" protocol, the client will generate a "message" that the server will process. The output from the server is returned to the client, that further modifies this output to produce the final tokens. The last client modification randomises these tokens in such a way that the server will be unable to identify to what issuance they belong.
The very cool thing is that this is the case even if the server tries to misbehave during their phase. This means that users only need to trust the client software, which we open sourced: https://github.com/kagisearch/privacypass-extension
Some posters are mentioning blind signatures, and indeed Privacy Pass can utilise these as a building block. To be precise, however, I should mention that for Kagi we use "Privately Verifiable Tokens" (https://www.rfc-editor.org/rfc/rfc9578.html#name-issuance-pr...) based on "oblivious pseudorandom functions" (OPRFs), which in my personal view are even cooler than blind signatures
If you can get Kagi to agree to it, definitely write a blog post on their behalf, please.
FWIW, the person you're replying to did write most of the blog post. We work together at Kagi on Privacy Pass.
1 reply →
That's apparently explained in their citation [1], the paper about cryptographically anonymous token protocols. It's not a simple plaintext token.
https://news.ycombinator.com/item?id=19623110 ("Privacy Pass (cloudflare.com)", 53 comments)
Yep, in fact Cloudflare are the original people who came up with this, when people were complaining about seeing turnstile screens too often
The tokens are "generated" on the client, and the server just gives the client enough information to make that locally generated token become "valid", without being able to link that token to a specific validation attempt
So basically the server signs the token and afterwards the server can verify its own signature for every request with that token?
looking at it from a high level, it doesn't appear the final token ever leaves the client till it's being redeemed. There's a middle step that does get signed, but this part is not what is sent.
Exactly the question I had in mind. You can't rely on server side trust so I'm curious if I just misunderstood something...
I think the extension they're using being open source helps with this? because it can be checked in there? not sure
I believe "Privacy Pass" uses blind signatures, so the token that the TokenResponse contains can't be correlated to the one provided in the search query, if I understand it correctly.