Comment by dooglius
2 days ago
I am not an expert in the underlying cryptography, but the claim is indeed that the cryptographic approach makes it impossible for them to link the key to the queries in the backend.
2 days ago
I am not an expert in the underlying cryptography, but the claim is indeed that the cryptographic approach makes it impossible for them to link the key to the queries in the backend.
Sure! But there is a stage where they generate those keys for you and give them to you. You need to be logged in to get that page. That is trust there.
No, issuer-client unlinkability is a feature of the design. The token is finalized by the client using private inputs so Kagi never actually sees the redeemable token (until it's redeemed).
https://blog.kagi.com/kagi-privacy-pass#token-generation:~:t....
https://www.rfc-editor.org/rfc/rfc9576.html
Using the example doc you’re citing from kagi.com - though not the RFC, I don’t have the time to dive into that one at the second, I see that a session token plus some other stuff is passed in and a token comes out.
Where does it show that on the Kagi backend they couldn’t, theoretically, save the session key before performing the token response?
1 reply →