Wow, the authors of that ring signature paper from a few days ago have already updated the paper after I emailed them

Kudos to them for such a quick response

They kept the timing data but noted the flaw, and produced a safe variation but did not include timing data for it

It would be interesting to see the comparison to CLSAG

Same link as before: eprint.iacr.org/2020/333

Dear chatters, please join ##ComputerTech123 - the best IRC channel. Regards, -ComputerTech

Dear chatters, please join ##ComputerTech123 - the best IRC channel. Regards, -ComputerTech

Dear chatters, please join ##ComputerTech123 - the best IRC channel. Regards, -ComputerTech

No thanks

OK, was looking over IACR 2020/333 update, which proposes a modification to their original linkable ring signature construction...

In appendix C, they present a Monero-compatible version of the signature that removes the use of a fixed-base key image

However, the construction basically says "use an AOS ring signature with these public keys, this private key, and this list of generators"

Hmm, nvm... I was using the AOS' signature, which doesn't work with a variable generator

[keybase] <seddd>: boldsuck lel, good nym

seddd: what are you talking about?

[keybase] <seddd>: AOS signature?

Yes, see the paper for citation and description

[keybase] <seddd>: sarang: nothing, some keybase user

[keybase] <seddd>: will do

I wonder about the generality of their results, since the use of variable generators in the "pass to ring signature" step isn't universal

With a fixed generator it doesn't seem to be a problem

but then you run into the tracing issue that they wish to avoid

[keybase] <seddd>: So in AOS they are using variable 'g' with every ring dig? Not sure I understand

[keybase] <seddd>: sig*

[keybase] <seddd>: need to read the revisions

Looks like they use a per-index generator `G + e_1*H(P_i)` at index `i`

Which works for AOS, but not for AOS'

So their Appendix C variation does not work in the general ring-signature case if you use the required variable-base key image

I suspect this means the security proofs won't hold in general for the Appendix C variation

But I've written to the authors to ask about this

And there's no way that the AOS variant (which does appear to work) would be more efficient than CLSAG in verification anymoore

*anymore

Hmm, although maybe I'm speaking too soon

Since you'd only have a single multiexp operation in each hash operation

I should code it up and see

It'd probably require a new security analysis to show the desired properties

Might be worth coding the AOS variant to see

The AOS' variant had the advantage of being parallelizable, which would have been pretty nice

[keybase] <seddd>: parallelizable codes always nice :)

Unfortunately that's the variant that doesn't work with variable generators :/

[keybase] <seddd>: will re-read the clsag paper for comparison on what these authors are trying to do

Their idea was was to generalize the multi-dimensional key vector idea so it could add linkability to different non-linkable ring signature constructions

and then you could choose the ring signature that provided the efficiency you want

A neat idea, but it seems to break down without a fixed-base key image (except in select cases, like AOS)

Their fixed-base AOS variant showed (according to their data) a lot of of improvement over CLSAG for verification times, but it's not clear how much of that was because of the removal of per-index public key hashes, which you need in the variable-base case

Doing a quick modification of the CLSAG test code should show what the actual verification difference is for the AOS variant

Do folks want to have a research meeting this Wednesday as usual, or ought we cancel it due to ongoing crazy world circumstances?

thisisfine.gif . not that I usually provider more than silly exclamations, but ..... i enjoy the meetings, and appreciate efforts towards relative normalcy.

I'm fine either way. I assume that there will be generally less to share overall, since folks may need time to take care of themselves, their families, and their communities

I plan to be around regardless FWIW

(barring any unexpected circumstances)

Until then, I'll be working on peer review for IEEE, as well as continuing investigation of the IACR 2020/333 preprint update

My initial estimates suggest that 2020/333 has competitive performance with CLSAG, so I'd like to dig deeper on that

oh churning. old.reddit.com/r/Monero/comments/fn…ything_monday_march_23_2020/flajvf2

Huzzah, IEEE review complete