3 ms·

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 ne

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.

SomeoneOnTheWeb 2y ago
Exactly the question I had in mind. You can't rely on server side trust so I'm curious if I just misunderstood something...
- deleted 2y ago
  [deleted]
- thibaultmol 2y ago
  I think the extension they're using being open source helps with this? because it can be checked in there? not sure
lxgr 2y ago
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.
perihelions 2y ago
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 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 https://news.ycombinator.com/item?id=19623110 ("Privacy Pass (cloudflare.com)", 53 comments)
- promiseofbeans 2y ago
  Yep, in fact Cloudflare are the original people who came up with this, when people were complaining about seeing turnstile screens too often
ajayyy 2y ago
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
- sebazzz 2y ago
  So basically the server signs the token and afterwards the server can verify its own signature for every request with that token?
  - faeranne 2y ago
    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.
fvirdia 2y ago
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 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-protocol-for-priva 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
- hansvm 2y ago
  If you can get Kagi to agree to it, definitely write a blog post on their behalf, please.
  - abound 2y ago
    FWIW, the person you're replying to did write most of the blog post. We work together at Kagi on Privacy Pass.
    - hansvm 2y ago
      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 :)

SomeoneOnTheWeb 2y ago

Exactly the question I had in mind. You can't rely on server side trust so I'm curious if I just misunderstood something...

deleted 2y ago
[deleted]
thibaultmol 2y ago
I think the extension they're using being open source helps with this? because it can be checked in there? not sure

lxgr 2y ago

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.

perihelions 2y ago

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 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 https://news.ycombinator.com/item?id=19623110 ("Privacy Pass (cloudflare.com)", 53 comments)

promiseofbeans 2y ago
Yep, in fact Cloudflare are the original people who came up with this, when people were complaining about seeing turnstile screens too often

ajayyy 2y ago

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

sebazzz 2y ago
So basically the server signs the token and afterwards the server can verify its own signature for every request with that token?
- faeranne 2y ago
  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.

fvirdia 2y ago

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 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-protocol-for-priva 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

hansvm 2y ago
If you can get Kagi to agree to it, definitely write a blog post on their behalf, please.
- abound 2y ago
  FWIW, the person you're replying to did write most of the blog post. We work together at Kagi on Privacy Pass.
  - hansvm 2y ago
    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 :)