waxwing on Nostr: First thing is that signatures are publically verifiable; generally when you want ...
First thing is that signatures are publically verifiable; generally when you want verifiability restricted, you use structures like HMAC which can only be checked with the/a secret.
I read your description several times. For the second paragraph (the first, I'll come back to), I *think* what you mean is the case where *you* (A) are giving a user (B) a signature, but you don't want them to be able to re-transmit it or share it? There's several ways to look at it but it depends on details of your use case. First thing to remember is that non-interactive signature schemes that we use are built from *interactive* identity protocols. The latter are *not* transferrable, but they are interactive. So, if A wants to convince B that the message being transferred is indeed from A who owns priv a, just follow a standard 3 pass commit, challenge, response (sigma-protocol).
Alternatively, it's often the case that you're not trying to keep any data secret, you're just trying to make the protocol disallow reuse. Then it can be fine to just include context into the message being signed. If instead of signing "Hello" I sign "Hello from A to B" then if B tries to send to C, the protocol can disallow it because the message does not contain "B to C".
Back to the first paragraph, I see three different things being requested: that the signature (s) be tweaked with a pubkey (to s' say), that the signature is verifiable only with that private key, and that s' is not linkable to s.
This feels like asking for 6 impossible things before breakfast :) Signatures can be tweaked easily (see the adaptor concept), but to state the obvious, they can't be tweaked with a scalar you don't know. So if user B has secret key b, s' = s+ b is verifiable by people not owning b but knowing B (that's adaptors), but the opposite seems impossible: to have s' be verifiable *only* if you know b, but constructible *without* b. That's kind of opposite to how public key crypto works; the world knows B, not b. That is even setting aside the problem of s not being linkable to s'.
Also BIP340 uses key prefixing (pubkey in hash), which means taking existing signatures and malleating them is impossible.
I read your description several times. For the second paragraph (the first, I'll come back to), I *think* what you mean is the case where *you* (A) are giving a user (B) a signature, but you don't want them to be able to re-transmit it or share it? There's several ways to look at it but it depends on details of your use case. First thing to remember is that non-interactive signature schemes that we use are built from *interactive* identity protocols. The latter are *not* transferrable, but they are interactive. So, if A wants to convince B that the message being transferred is indeed from A who owns priv a, just follow a standard 3 pass commit, challenge, response (sigma-protocol).
Alternatively, it's often the case that you're not trying to keep any data secret, you're just trying to make the protocol disallow reuse. Then it can be fine to just include context into the message being signed. If instead of signing "Hello" I sign "Hello from A to B" then if B tries to send to C, the protocol can disallow it because the message does not contain "B to C".
Back to the first paragraph, I see three different things being requested: that the signature (s) be tweaked with a pubkey (to s' say), that the signature is verifiable only with that private key, and that s' is not linkable to s.
This feels like asking for 6 impossible things before breakfast :) Signatures can be tweaked easily (see the adaptor concept), but to state the obvious, they can't be tweaked with a scalar you don't know. So if user B has secret key b, s' = s+ b is verifiable by people not owning b but knowing B (that's adaptors), but the opposite seems impossible: to have s' be verifiable *only* if you know b, but constructible *without* b. That's kind of opposite to how public key crypto works; the world knows B, not b. That is even setting aside the problem of s not being linkable to s'.
Also BIP340 uses key prefixing (pubkey in hash), which means taking existing signatures and malleating them is impossible.