Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linkable singature tag not working #16

Open
russanto opened this issue Oct 14, 2019 · 4 comments
Open

Linkable singature tag not working #16

russanto opened this issue Oct 14, 2019 · 4 comments

Comments

@russanto
Copy link

I read the implementation of the uaosring.py and I see that returned tag is the result of multiplying the message, and not the public key list hash (like pointed in the reference paper), with the private key.
In this way signing two different messages with the same identity is not resulting in the same tag, so it is not possible to link the two generated signatures.

@HarryR
Copy link
Owner

HarryR commented Oct 15, 2019

The message is whatever you want it to be, in many cases you will want the message to be the list of public keys and some other arbitrary string uniquely identifying something.

@russanto
Copy link
Author

Yes, the message can be whatevere you want, public key list included, but the expected behaviour of a linkable ring singature should be that if a signer signs two different messages the tag coming out from the two signatures should be equal in order to link the two signatures and detect that a signer signed twice (the hypothesis is that we're always refering to the same public-key list).
If the tag is the result of applying the one-way function to the message instead of the public-key list, you can't achieve linkability; tag would be always different even if the signer is the same.
That's why for the tag calculation you should always use the public-key list that is constant instead of the message that potentially changes for each signature.

@HarryR
Copy link
Owner

HarryR commented Oct 15, 2019

I understand.

The tag is specific to the message, if the same message is signed multiple times by the same key it will derive the same tag. However, restricting the message to always be the list of public keys is too restrictive for several protocols, e.g. where you may want the same group of public keys to signal on different topics, but you do not want the same key to signal more than once on any given topic, or want different groups of public keys to signal only once (where binding the message to a randomly chosen group of public keys would create multiple tags.. which wouldn't give you linkability)

It is up to the implementor to supply a message which guarantees unique tags in whichever situations are necessary for the protocol.

@russanto
Copy link
Author

OK, now I understand what you intend for the tag and I agree that restricting the message to always be the list of public keys is too restrictive for several protocols. In fact what I mean (and also the referring paper) is that in order to achieve linkability (linkability of the same signer referring to the same public-key list), exactly as protocol that you provided by example (same group signing on different messages), tag calculation should not involve information coming from the message, otherwise the only way to obtain the same tag is to sign the same message; the only application of current implementation is what you pointed "if the same message is signed multiple times by the same key it will derive the same tag". That's why I think that tag calculation should only involve public-key list and signer private key while message will be only part of the ring formation. If you need this ("if the same message is signed multiple times by the same key it will derive the same tag") than one can involve message also in tag calculation.

What I finally mean is that data for tag calculation and message shall be capable of being different and only if needed taken as equal; in this way you would have freedom to face all protocol that you pointed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants