The to date scariest thing I found out about Monero is that the people behind Monero host cryptographic tools that are only crypto theater. For years. And without an issue tracker, people taking Monero devs seriously will inevitably fall for the temptation to use these tools.

https://github.com/monero-project/urs promises:

"URS can be used to sign plaintext or binaries anonymously (among a group of known users). That is a user can sign a message, hiding among a group of known/registered users, that prevents the verifier from revealing the signer's identity other than knowing that it is in the set of registered users."

7 years ago, these claims were found to be false and the Monero devs never removed this repository or marked it as dangerous?

https://kewde.github.io/urs

Reply to this note

Please Login to reply.

Discussion

Let me see if I get what you're saying.

The Monero devs created a crypto tool to communicate anonymously with other Monero users. But the tool doesn't work properly. It's not actually anonymous. And they didn't announce this on the repository. So uninformed users may have been compromising their own privacy over the past 7 years by using the tool which been known to be broken all this time.

Is that correct?

Almost. The tool is a library, so I don't know what they did or intended to use it for but it can be used for that.

It doesn't look like a very popular repository (not very many stars). For that reason alone I think people should be skeptical of its robustness for highly important use cases (such as protecting your privacy) until doing some due diligence first to ensure it can deliver.

What's wrong with the library exactly?

Oh, very interesting! For some background for readers: the idea of using a ring signature to sign code is to help the anonymity (in a limited set) of the author; not a crazy idea, by any means. However the vulnerability mentioned is what interests me here: because around 2016, shortly after the Confidential Transactions idea was published by Maxwell and Poelstra, the Monero devs got understandably excited, because the idea of an anonymizing cryptocurrency with plaintext amounts obviously isn't great. So their initial proposals to use Confidential Transactions contained flaws, and I think the first one was exactly the one mentioned here: usingn H(data)*G for the alternate basepoint. This is an incredibly bad failure because it 100% breaks the anonymity immediately (I won't explain to avoid boring people), and also because it's a very basic error. I believe it was Jonas Nick who read their paper and pointed it out, and also pointed at a second much more subtle but very serious flaw in a proposal they had. My memory may be failing me there, but anyway something along those lines happened, but it never got into the code of Monero the cryptocc. So yeah it's really interesting if it *did* get into this project and then went unnoticed/undeleted.

They did delete the repo since I posted this and made a PR to update the Readme to point to the issue.

So do you know of any solid ring signature scheme for my use case? I think, "linkable" is ok but not required.

I just noticed, nostr:npub12ekpvme6m2cv37a9mgq4kzemej8tx6ttg40j582rh77ewpvkg65qj8tq0f is on nostr. He looked into porting what I think I would need to JS noble-curves last year: https://github.com/paulmillr/noble-curves/issues/146

What's your use case? The one they implemented here?

But no, I don't know of a library that implements ring signatures. The Borromean one is really just a small optimisation of the general AOS design, which itself is a natural generalization of Schnorr to 1 of N secrets. See reyify.com/blog/ring-signatures/ (for anyone unfamiliar with the ideas).

I'm maintaining walletscrutiny.com and the people most knowledgeable on bitcoin wallets are bitcoin wallet developers but they are also very reluctant to talk about the flaws of their competitors unless in private with a beer.

I want to provide a tool where they can establish to be one of 100 wallet developers and thus report as a self-accredited expert. So we would identify nostr accounts that work as wallet developers and each of them can then write as a member of that group anonymously.

So the scheme should not require all the wallet devs to participate in a setup ceremony and there should not be any secret setup neither. I need it to work for the first expert willing to throw a stone, with a set of npubs of his choice should my choice not be to their liking.

For our purpose, linkability would be ok as it would prevent some Sybil attack where one author pretends to be 20 but if it's vastly easier to have non-linkable ring signatures, that's ok, too.

Yes, right. I get where you're coming from. I agree that linkability is a nice-to-have feature here, maybe not essential. For spontaneity, yes, you get that with the AOS style (all of its derivatives, LWW, LSAG etc), I guess in practice it only ever mattered in cryptocurrency; because the nice idea of spontaneous ring formation rarely ended up being useful in practice; people have to have a key that you can spontaneously choose; if the number of such people is small enough, why not choose them all? IIRC Liu Wei Wong actually covered this point in one interesting way, suggesting that you could spontaneously form ring sigs over keys of different types (e.g. RSA and ECDSA etc.).

From a 20 minute look through the results for "ring signature" on github, I agree with you that it's hard to impossible to find an existing library that is reputable enough/well enough developed to be usable for a generic ring signature application of the type you're looking for. It's, I guess, a function of the fact that ring signatures never reached the threshold of common usage that led to them being included into the big crypto toolkits like you find in popular languages like Python and Javascript etc. After all they were never standardized by NIST and I don't think an RFC exists.

It might be better to just allow anonymous submission *without* a keyset, like they do for whistleblowers. The nature of such reports is that they can be verified anyway, right, so that you don't need to trust the one reporting.

Ephemeral keys without group membership. Hmm ... then it will be free for all and spammy. Verifying the non-spam might be possible but drown in low effort accusations maybe? Also I want nut zaps to be possible. With ephemeral keys, who will store those?

I didn't actually mean ephemeral keys, but I suppose such a thing is possible. I also didn't consider zaps but that seems to add nontrivial complexity either way.

Thanks for bringing this up. Someone brought your note to the attention of Monero IRC group and they removed it. Agreed with you it should have been taken down a long time ago. The original also added a warning to it a few days ago.

Removed:

https://github.com/monero-project/urs

Warning added:

https://github.com/meling/urs

The warning they added upon my initiative. I suggested to keep the repository up for posterity. Who knows who's using the library and with the repo disappearing, they might just wonder why it's gone.

Thanks for bringing this up. Someone brought your note to the attention of Monero IRC group and they removed it. Agreed with you it should have been taken down a long time ago. The original also added a warning to it a few days ago.

Removed:

https://github.com/monero-project/urs

Warning added:

https://github.com/meling/urs