Hacker News Reader

Comment by cobertos | Hacker News Reader

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.

View on HN

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.

Oh, interesting. Maybe it's just on mobile, but no authors are rendering on the article for me.

Anywho, the person I replied to seemed to be willing and able to go a technical level deeper than the article, and that's something I'm also interested in reading. It sounds like they'd be allowed :)

That's apparently explained in their citation [1], the paper about cryptographically anonymous token protocols. It's not a simple plaintext token.

https://petsymposium.org/popets/2018/popets-2018-0026.php ("Privacy Pass: Bypassing Internet Challenges Anonymously")

I think Cloudflare implemented the same thing? At least the HN comments link to the same paper,

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.

Reply on news.ycombinator.com