Replying to Avatar SatsAndSports

I'd like your feedback on a cryptographic idea I have for Cashu. The idea is to allow Alice to blind a message, but where she cannot unblind it. Only the final recipient of the token, Carol, can unblind.

Using the Cashu protocol, where Alice is working with the mint (Bob), to prepare a token (x,C) which she will send to Carol. Let's define Carol's private key as 'f', with her public key as 'F=fG'

In the standard protocol, 'r' is a random integer selected by Alice. I propose instead that Alice selects a random integer r_. Instead of adding 'r*G' to Y in the third step (see the 'blinding' step in screenshot below), I propose that she instead adds 'r_ * F', to get 'B_ = Y + r_ * F'

This is equivalent to 'B_ = Y + r * G', where 'r = r_ * f'. Therefore, Alice has managed to blind it with 'r', but Alice doesn't know what 'r' is. Only Carol knows 'r', as only Carol knows 'f'. Carol is the only person that can compute 'r = r_ * f'

In the standard protocol, Alice unblinds and sends (x,C) to Carol. But here, Alice cannot unblind. Alice sends r_ and C_ to Carol instead. i.e. she sends (x, r_, C_) to Carol.

Carol can then reconstruct C, the 'unblinding' in the screenshot below, as 'C = C_ - r * K' , where 'r = r_ * f'.

Thoughts? While I have a background in maths, I'm very new to elliptic curves, so I'm assuming there's an attack surface that I'm missing.

Motivation: The original motivation is for 'deterministic outputs' in the Spilman channel that I'm working on with the Cashu folks (@calle), but this idea might also be useful in normal Cashu usage where the receiver (Carol) is offline. An offline receiver could publish their public key and the online sender can prepare a suitable 'BlindSignature' from the mint. Carol (and only Carol) is able to unblind and Carol can validate the DLEQ proof (NUT-12) offline

https://github.com/cashubtc/nuts/blob/main/00.md

While Alice can't unblind on her own, there might be a problem because of the fact that Alice and the mint (Bob) can work together (because, between them, they know 'r_' and 'k') to unblind via:

C_ - r_ * k * F

Is this a problem?

Reply to this note

Please Login to reply.

Discussion

I don't think *this* is a problem. If Alice and the Mint collude they can always unblind C_, so this isn't really a downgrade from standard cashu.

However, there is an attack where Alice just lets the Mint sign Y twice. Once with Carol's public key B_ = Y + r * F and once the standard way with B_' = Y + rG.

Now, (x, r_, C_, DLEQ) looks like a valid token to Carol even when offline. However if Alice spends her token before Carol, Carol's token will get denied because the secret x is already in the Mint's spent set.

An idea to fix this:

1. Carol generates a bunch of secrets x, blinds them (B=Y+rG), and publishes these "Blank Checks" (B_'s) somewhere. She can then go offline.

2. Alice grabs a B_, pays the Mint to sign it (C_), and sends it to Carol. Alice cannot have Y signed twice (like in the prior attack) because she doesn't know x.

3. Carol receives C_ and the DLEQ proof. She verifies the proof against her original blank checks and the Mint's public key. If one of them passes, she has cryptographic proof that C_ is the valid signature for her specific B_. Since only she holds the secret x, she knows the token is safe and unspent. She can unblind it later when she is back online.

Not sure if I'm making any mistakes or the first step defies the purpose you want to use this for. I'm pretty new to all of this myself. Would love to hear what you think!

Just realized that for the 'Blank Check' approach to work, we have to make sure that only a single party has access to a specific set of blank checks.

Otherwise, we run the risk that a check gets used twice but Carol can only redeem it once.

If we have to restrict access to the checks, that probably defeats the original purpose: 'An offline receiver could publish their public key and the online sender can prepare a suitable BlindSignature from the mint.'

"She can *spend* it later when she is back online" not "unblind".