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.
 

 🫠 

 The idea is indeed to disallow re-sharing. 

Picture a company relay. All the information should be strictly contained into that main relay. 

However, for Nostr clients to work, they need to verify events by themselves. Which means they receive a full copy of the event and can re-broadcast that copy to another relay very easily.

That creates a problem.

We could just delete the signature field and ask Nostr clients to not verify and "trust" that the company or its relay is not modifying the message from its original author. But relying on trust defeats the purpose of using Nostr in the first place.

Since the company relay authenticates who is connecting to them, it could easily modify the event to make sure only that user can verify it. 

My initial solution was simply to encrypt the signature field to the pubkey of the connecting user. Then the client would have to decrypt it before verifying. The issue is that once the user has decrypted, the user has access to the full signature in plain text and can add it back in the event and re-share it with another relay. 

Which is not really a solution to the problem.

This led me to the question in this post. How do we make a modified event signature that only one user can verify. It could be still possible to allow other people to verify the new event, but that implies having to make the user's main private key public and hopefully there is enough sensitive information in that private key to serve as a deterrant from users doing so.  

 Right, thanks, that helps quite a lot. I do get where you're coming from with the "leak private key" concept, that's of course intrinsic/fundamental to Schnorr sigs so it makes sense to at least think about it as a deterrent.

It's pretty whacky, but this combination gives you something like what you want: imagine 2 of 2 musig between user A and relay R. A gives R an adaptor on its partial sig sigma_A' where the adaptor secret is its own private key. Then R gives sigma_R and A can *internally* verify the full signature on the musig aggregated key against the message. If it broadcasts that full signature, it leaks its private key. 

 Interesting... I need to do some testing, but maybe this is the beginning of a modified Nostr protocol for enterprises and trully private groups.

I do think there is a lot of need and money waiting for solutions in that realm.  

 Interesting it is :) But practical? I guess maybe not? We need a version of these ideas that doesn't involve non-trivial interaction between the client and the server (relay), right? I'm finding myself drawn back to "HMAC"; because that was always the traditional solution to this problem, i.e. only the two parties involved in the conversation can verify. There are so called "algebraic HMACs" that can use EC arithmetic instead of hashes. I'll take another look at that.