14:29:28 <sarang> Hi; hope everyone is doing well
14:29:51 <sarang> I'll be finishing some formal peer review today, wooo
14:30:23 <selsta> sounds fun :P
14:30:44 <sarang> Even though the IEEE S&B event is delayed, they'll still maintain the same review schedule
14:31:30 <sarang> As might be expected given the current world situation, the review process has been... slow
15:54:57 <real_or_random> sarang: I can assure you that review processes are always that slow lol
15:55:18 <real_or_random> so kudos for working on it early! :D
15:55:21 <sarang> Heh, noted
15:55:42 <sarang> I try to get my reviews done earlier
16:01:10 <sarang> I remember one time my collaborator and I waited over a year for a review...
18:34:48 <sarang> New LRS proposal: https://eprint.iacr.org/2020/333
18:35:14 <sarang> Still reading, but I think it assumes a linear fixed-based key image, which is traceable and not suitable for use
18:35:38 <sarang> it also appears to use a fixed-index key matrix in one of its constructions, which we also should not use
18:36:07 <sarang> (so I also think its comparison to MLSAG/CLSAG as deployed is not accurate either)
18:36:21 * sarang will keep reading
18:38:36 <sarang> If needed, I can contact the authors with this information
19:13:00 <binaryFate> Is this the post peer-review version? In any case maybe it is good to contact them asap wrt. "so I also think its comparison to MLSAG/CLSAG as deployed is not accurate either"?
19:26:09 <sarang> It's not clear if that is the case
19:26:16 <sarang> but I want to give it a thorough read first, of course
19:26:45 <sarang> But at any rate, the use of a fixed-base linear key image means it's not secure in practice anyway
19:28:14 <sarang> ^ binaryFate
19:30:15 <sarang> It also has a pretty restrictive security model too
19:30:41 <sarang> Basically the entire recent CLSAG update work has been to remove such restrictions
21:08:20 <sarang> Ah ok, I was confused by the authors' notation in that preprint
21:08:39 <sarang> When they say `m`-ring signature, they mean in the context of key vector dimension, not inputs
21:08:59 <sarang> The use of a fixed-based key image still means it couldn't be used due to linking
21:11:16 <sarang> Their signature size is identical to CLSAG
21:12:54 <sarang> They claim a lot faster performance, even for non-parallel generation and verification, but don't provide a link to their code or any relative operation counts
21:13:29 <sarang> e.g. if the speedup comes from using a fixed key image base instead of hashing, then that doesn't apply due to the security problem
21:14:33 <sarang> So I take back earlier when I thought that the comparisons were not accurate... I don't think there can be a comparison without fixing the key image flaw first
21:15:11 <sarang> Heck, I should run an operation count to see
21:21:48 <sarang> ^ binaryFate
21:30:15 <sarang> https://www.irccloud.com/pastebin/fgYB8cC8
21:30:21 <sarang> ^ proposed email to the authors
21:32:13 <sarang> comments welcome
21:34:20 <sarang> Whoops, s/MSLSR/MSLRS/g
21:35:04 <sarang> This is interesting in part because there doesn't appear (at first glance) to be anything wrong with their security proofs
21:35:16 <sarang> but rather a consequence of the security model not capturing the one-time address construction
21:35:29 <sarang> CLSAG's security model doesn't either, but is constructed with the key image linking problem in mind
21:36:23 <sarang> and RCT3/Omniring/Triptych/Triptych-2 don't have to worry about it in the same way, either because of the VRF construction or (in the case of at least Omniring) building in the OTA construction into the protocol directly
21:37:06 <derpy_bridge> [keybase] <seddd>: _wonders who gets paper 2020-420_
21:37:25 <derpy_bridge> [keybase] <seddd>: If it's a hashing paper, I'm gonna die
21:37:26 <sarang> Ah, RCT3 does too, that's right
21:43:23 <binaryFate> sarang I can't comment on the fundamental meat of it but that's a polite and very clearly written email, very good
21:44:49 <sarang> Also a bit funny is that this exact same issue is what plagues DLSAG too
21:44:50 <sarang> !
21:45:14 <binaryFate> Do you know the authors? Does it happen often that "unknown" researchers publish something clearly referecing Monero with aim to potentially improve something?
21:45:38 <sarang> I'm a bit surprised that they published this on IACR 2-3 years after the conference year listed
21:46:00 <sarang> It's not the first time that a Monero-related preprint has appeared unexpectedly on the archive
21:47:08 <sarang> I get why they wouldn't necessarily contact MRL, if they fear getting their research scooped (I certainly wouldn't do such a thing)
21:48:15 <sarang> Anyway, I'll send that email
21:48:23 <sarang> No clue if they'll choose to revise
21:48:39 <sarang> but at any rate, we certainly won't be deploying the signature construction from the paper
21:50:07 <binaryFate> gotcha
21:50:53 <sarang> Hopefully it doesn't gain too much traction for potential deployment in production anywhere
21:51:02 <sarang> It's still interesting from a theoretical perspective
21:51:33 <binaryFate> Pity they didn't reach out, no matter the reason :/
21:51:47 <sarang> Eh, I can understand it if they don't want to get scooped
21:51:54 <derpy_bridge> [keybase] <seddd>: Doubt it would if there was a statement about it's brokenness (mb optimistic)
21:52:11 <derpy_bridge> [keybase] <seddd>: Yeah sucks to be them
21:52:11 <sarang> Well, the construction itself isn't broken, given its security model
21:52:17 <sarang> just not safe for the application they suggest
21:52:30 <derpy_bridge> [keybase] <seddd>: Ah, gotcha
21:52:57 <sarang> I happen to think that revising to note this would be important, to avoid it being implemented in a way that's unsafe
21:53:08 <sarang> but it's their paper; they can do what they wish
21:53:39 <derpy_bridge> [keybase] <seddd>: True, hopefully they'll take it as a kindness
21:54:03 <sarang> Part of why the preprint system is cool IMO is to get feedback from other researchers like this
21:54:26 <sarang> Easier to iterate on an idea, in theory
21:54:54 <sarang> The downside is it's easy to fall into the trap of thinking that a preprint has been subject to scrutiny or review (I fall into this trap sometimes, for sure)
21:55:00 <sarang> even if you know that isn't the case
21:57:22 <derpy_bridge> [keybase] <seddd>: Right, same. Do they have a "this is solid + reviewed" section?
21:57:32 <derpy_bridge> [keybase] <seddd>: Or way of tagging?
21:58:49 <sarang> No
21:59:07 <derpy_bridge> [keybase] <seddd>: yeh, didn't think so
21:59:08 <sarang> Preprint archive is just a place to post relevant original research
21:59:42 <sarang> Papers do get a minimal review by the editors, but only for apparent relevance
21:59:52 <sarang> and that seems entirely reasonable
22:00:17 <derpy_bridge> [keybase] <seddd>: Yeah, and then it's just up to peer review?
22:00:37 <derpy_bridge> [keybase] <seddd>: I mean for getting feedback
22:00:57 <xmrmatterbridge> <midipoet> To be honest, I don't understand how the "preprint process" has any relation to good science.
22:01:33 <derpy_bridge> [keybase] <seddd>: how so?
22:01:36 <xmrmatterbridge> <midipoet> But perhaps I don't understand it properly
22:01:44 <sarang> I think it's hugely beneficial for sharing research with other researchers
22:01:55 <derpy_bridge> [keybase] <seddd>: +1
22:01:59 <sarang> I think it's not generally useful (and sometimes even harmful) outside of that
22:02:09 <sarang> e.g. if media picks up on a preprint and doesn't understand the process
22:02:27 <xmrmatterbridge> <midipoet> Yes, perhaps that is the problem.
22:02:38 <sarang> But I think the benefits outweight the costs
22:03:15 <xmrmatterbridge> <midipoet> It seems that it is essentially a great big non-peer reviewed white paper respository.
22:03:32 <sarang> for sure
22:03:36 <xmrmatterbridge> <midipoet> So I suppose to speed up research it helps
22:03:45 <sarang> indeed
22:03:58 <sarang> Especially because the peer-review process can take a long time, if it happens at all
22:04:08 <sarang> There aren't enough journals or conferences or reviewers for all the good papers out there
22:04:21 <sarang> and peer review doesn't guarantee quality peer review either
22:04:32 <sarang> so it's all a balance of risk, I suppose, like everything in life
22:04:50 <xmrmatterbridge> <midipoet> But I didn't think that cryptography would be a field that prioritises quantity over quality (perhaps those aren't the correct descriptors)
22:05:03 <sarang> It's a really active field
22:05:10 <sarang> that often has a lot of applications
22:05:19 <xmrmatterbridge> <midipoet> There are enough authors, but not enough reviewers?
22:05:26 <sarang> That seems accurate
22:05:31 <sarang> Because the authors are also reviewers...
22:05:42 <sarang> who are often professors who have their own classes and research etc.
22:05:50 <sarang> and review is time-consuming
22:06:17 <sarang> Not to mention that submitting papers is a linear process that can't be done in parallel
22:06:27 <sarang> i.e. you need to submit, then wait for a response, then submit elsewhere, etc.
22:06:35 <sarang> you can't usually submit to multiple destinations at once
22:06:54 <sarang> That might be more reasonable in some fields, but cryptography moves quickly
22:07:06 <xmrmatterbridge> <midipoet> Yes sarang, I understand the process. But sometimes the slower pace means better overall quality of research
22:07:09 <sarang> so having access to interesting new techniques is important and useful
22:07:16 <sarang> Why would that be?
22:07:31 <sarang> It's not like review is slow because the reviewers take the entire time for the process
22:07:48 <sarang> or that non-parallel submission means you do more research on that topic
22:08:00 <xmrmatterbridge> <midipoet> Like, what percentage of the preprints, in you opinion, may have significant deficiencies/be repeated work, not reference previous work, etc?
22:08:24 <sarang> Well, most work builds on previous stuff in the field
22:08:45 <xmrmatterbridge> <midipoet> Those new techniques could be shared in different formats than non-reviewed papers, could they not?
22:08:46 <sarang> Or is inspired by current research trends
22:08:53 <sarang> Like what?
22:09:33 <xmrmatterbridge> <midipoet> no, I meant the review process means that submissions are usually of higher quality, as they dear rejection.
22:09:38 <xmrmatterbridge> <midipoet> *fear
22:09:52 <sarang> Some, perhaps
22:09:56 <sarang> Certainly not all
22:10:03 <sarang> but good point
22:10:18 <sarang> Although many good papers get rejected all the time
22:10:22 <sarang> and the process starts over
22:10:25 <sarang> :/
22:10:35 <xmrmatterbridge> <midipoet> I would say the vast majority of papers that are submitted to peer review are of higher quality.
22:10:57 <xmrmatterbridge> <midipoet> The rejection process is of itself a scientifically beneficial process
22:11:11 <xmrmatterbridge> <midipoet> Provided the review process is properly done, of course
22:11:34 <sarang> I don't think rejection is necessarily strongly correlated with quality
22:11:51 <xmrmatterbridge> <midipoet> Like, would you want this preprint process be applied to medicine?
22:12:04 <xmrmatterbridge> <midipoet> (though admittedly perhaps it is!)
22:12:11 <sarang> Absolutely, provided the results are applied properly
22:12:29 <sarang> I would certainly not want my doctor to give me advice based solely on a preprint
22:12:47 <xmrmatterbridge> <midipoet> And what about Law?
22:12:59 <sarang> I don't know enough about that field, sorry
22:13:06 <sarang> Anyway, we should move this to -lounge probably
22:13:31 <xmrmatterbridge> <midipoet> Well, I certainly wouldn't want legal advice given on a law non reviewed pre-print
22:14:29 <sarang> makes sense
22:14:56 <derpy_bridge> [keybase] <seddd>: right, but an impl on a pre-print under application for standardization isn't so bad.
22:15:30 <derpy_bridge> [keybase] <seddd>: especially under the assumption of change or total failure
22:16:24 <xmrmatterbridge> <midipoet> As an aside, it's interesting to see the guides for medical preprints (it is a thing, but with caveats)
22:16:27 <xmrmatterbridge> <midipoet> https://www.sciencemag.org/news/2019/06/medical-preprint-server-debuts
22:16:56 <derpy_bridge> [keybase] <seddd>: agree good impls and professional products/services should have a strong basis, vetted by multiple independent, reputable sources
22:17:36 <sarang> to -lounge !