RSA Blind Signature Authorisations
It’s useful for privacy to decouple authentication from request authorisation. When you sign in to Venice, you’re getting back a session cookie that you use to authenticate your requests to the chat endpoint.
https://en.wikipedia.org/wiki/Blind_signature#Blind_RSA_signatures
Instead, when you authenticate, your client can generate a blinded RSA token, and the authentication backend can sign that and return the signature to the client which can unblind it. The signed, unblinded token can be eligible for some number of requests / inferences / tokens. The client can use that signed token to authenticate its requests to the chat endpoint, which can track that token’s usage until it’s depleted.
The purpose of this is create a decoupled zero-knowledge relationship between the account information and the authorisation to consume resources.
If you use a zero knowledge SNARK to construct the blinded message, you can construct a more fine-grained partially blind message which the authentication backend can sign. As long as the constructed message is indistinct from the messages signed for other users, it’s k-anonymous to some degree.
Implementing this is pretty straightforward. I’d be happy to consult / help implement.
Log in to comment and vote
Comments2
Aquamarine Oak
Nov 19, 2025
It would be cool to enable API calls to be paid out of DIEM without disclosing the account the DIEM's coming from. Instead of using an API key, you could authenticate requests using blind-signed notes for uniform quantities of DIEM.
There would be an API endpoint where you request DIEM notes by submitting
M' = I * r^e % N(an identifier multiplied by a blinding, modulo RSA N), plus some requests for DIEM note denominations. The server would respond with a set of blinded signatures for the requested notes (S_i' = (H(amount, epoch, i) * M) ^ d % N).For each note, the requester would do
S_i = S_i' * (r^-1) % Nto recover a distinct signatureS_i = I * H(amount, epoch, i).They could spend these signatures by sending
(S_i, amount, i), which the inference API would verify asS_i ^ e ≡ H(amount, epoch, i) % N, and nullify them. Each inference request could spend arbitrary numbers and denominations, or could simply "top up" an inference-side account for each epoch without disclosing the source account.Aquamarine Oak
Jan 30, 2025
Forgot to log in. This is me.