Skip to main content

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.

Status: Backlog2 comments

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) % N to recover a distinct signature S_i = I * H(amount, epoch, i).

    They could spend these signatures by sending (S_i, amount, i), which the inference API would verify as S_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.