<sarang> GREETINGS <sarang> hi <seddd>: o/ <UkoeHB_> hi <SerHack> hi <sarang> Moving on, then, to ROUNDTABLE <sarang> Who wishes to share research of interest? <ArticMine> Hi <sarang> I can share a few things <sarang> I've completed some formal peer review for the IEEE S&B proceedings <sarang> and worked on analysis for a linkable ring signature construction in IACR 2020/333 <sarang> it claimed to be more efficient than CLSAG <sarang> However, the numbers assumed an insecure key image construction <sarang> The authors have already posted a revision, but it doesn't include numbers or new security proofs for the modified construction <sarang> Besides this, here's an update on some other projects... <sarang> For CLSAG, I am still waiting on the final go-ahead from suraeNoether, who is a coauthor on the paper <sarang> I finished code optimization and made a PR to moneromooo's branch, which has some nice verification speedups <sarang> For Triptych-1, its preprint has been updated at IACR 2020/018 <sarang> An MPC construction for key images is completed, and multisig/join analysis is still underway <sarang> For Triptych-2, its preprint has been posted at IACR 2020/312 <sarang> Multisig/join analysis is still underway <sarang> That's all for me <sarang> Any particular questions or comments? <nioc> how much verification speeedup for CLSAG? <seddd>: Do you need any more eyes on the CLSAG PR? <sarang> It's around 4-5% <nioc> nice <sarang> seddd: That would be welcome, once moneromooo integrates the new changes into the branch <seddd>: Ok, let me know, and I'll review <sarang> that'd be great <moneromooo> I did, I can push. <sarang> Oh excellent <ArticMine> 4-5% reduction in size? Verification time? <sarang> The only real changes from the paper's description is a modification to the public parameters that go into the challenge hashes, which allows for the speedup to happen <sarang> ArticMine: verification time <sarang> I didn't bother with generation stuff, since that's less important <sarang> Size is identical <sarang> The PR includes new performance tests with better direct comparison to MLSAG, if that's useful to anyone <seddd>: moneromooo: link? <ArticMine> So is this the version that is going for audit? <moneromooo> Not yet. <sarang> Presumably, but that's up to the audit workgroup <moneromooo> I'm rebasing it to master now, then will run tests, then push, then post a link. <sarang> moneromooo: excellent, then the CI workflow will operate properly <seddd>: awesome, many thanks <sarang> Any other questions for me? <sarang> Or does anyone else wish to share research topics? <seddd>: Mb but it involves pow of another coin, not sure appropriate <sarang> Perhaps suited for after the meeting <seddd>: Definitely <selsta> who is the audit workgroup? sgp? <sarang> sgp_ has been working to coordinate <sarang> As far as the CLSAG paper goes, if I don't hear from suraeNoether, eventually I suppose we'll just have to release the revised version without him <sarang> But I would prefer not to do that, since he's a coauthor <seddd>: Is suraeNoether not around rn? <sarang> He hasn't enabled public viewing on the overleaf version, and I don't have access rights to do that unfortunately <sarang> No, he is not around right now AFAIK <seddd>: k <sarang> Well, to respect everyone's time, I suppose we can move to ACTION ITEMS <UkoeHB_> update from me: proofreading is extended to this weekend as comments are trickling in at the last moment :p; I have received several good feedbacks so far <sarang> Ah ok, go ahead UkoeHB_ <UkoeHB_> current proofreading version is here https://www.pdf-archive.com/2020/03/22/zerotomoneromaster-v1-1-2/zerotomoneromaster-v1-1-2.pdf <UkoeHB_> that's all <sarang> Great, thanks <sarang> My action items are to complete my proofreading of Zero to Monero (it's been delayed; my apologies) <sarang> and to work on some Triptych-2 MPC math <sarang> Anyone else? <hyc> "research only, not for production use" inb4 sumo releases it and claims to be first <UkoeHB_> oh right, I made a small update to Janus mitigation <sarang> hyc: ? <sgp_> UkoeHB_: cool,, what? <seddd>: lul hyc <hyc> sorry, catching up from a couple days ago <UkoeHB_>https://github.com/monero-project/research-lab/issues/62#issuecomment-603079784 <seddd>: imagines sumo as yt commenter: "FIRST" <sgp_> UkoeHB_: none of that is implemented correct? <sarang> Off topic, folks! <UkoeHB_> correct <seddd>: srry <sarang> IIRC, the last time Janus mitigations were discussed in a dev meeting, there seemed to be mixed support <UkoeHB_> my action item is to go through all proofreading comments, and then this weekend finalize a for-publication version <UkoeHB_> sarang part of that seemed to be related to exactly how many pub keys and janus base keys it would require <UkoeHB_> full Janus mitigation would require: 1 Janus base key per transaction, #pub keys = #outputs for ALL transactions (not just tx with subaddresses as is the case now) <sarang> yep <seddd>: sounds like a lot of overhead, is that one of the main objections? <UkoeHB_> there is partial Janus mitigation, where normal addresses and subaddresses are split up; in other words, don't mitigate linking of normal addresses with subaddresses; that way only tx with subaddresses would need the janus base key <UkoeHB_> however, even with partial mitigation a lot more subaddress tx would be revealed as subaddress, as there are currently some optimizations that hide subaddress tx among normal tx <UkoeHB_> while with full migitation, normal address tx and subaddress tx would be universally indistinguishable <UkoeHB_> which iirc sarang was in favor of even outside of Janus <seddd>: +1 for the latter <sarang> Yeah, encouraging/enforcing indistinguishability is useful <UkoeHB_> the main objective is solving the Janus attack <UkoeHB_> which is currently undetectable <sarang> yes <seddd>: so what are the opposing arguments? <sarang> Transaction size is increased <sarang> that's a big counterargument <sarang> (literally) <seddd>: :) <sarang> So as happens always, there's a tradeoff on complexity (in this case, size and protocol changes) and indistinguishability <sarang> s/always/often <sarang> Worth noting that with CLSAG, standard tx size already drops from ~2.5 kB to ~1.9 kB <sarang> so there's some wiggle room <seddd>: are there potentially more compact full Janis mitigations? <sarang> Each added scalar/group element adds 32 bytes <seddd>: Janus* <UkoeHB_> this is the smallest known mitigation <ArticMine> Tx size is increased by how much? <UkoeHB_> on average, about 2.2*32 bytes per transaction <UkoeHB_> assuming 2.2 is the average output count <UkoeHB_> wait no, 32 + 1.2*32 <UkoeHB_> same thing lol <seddd>: What about encoding the extra basepoint in smth like a lookup table, where base points are indexed by the first 8? bytes <UkoeHB_> actually a tiny bit less than that, taking into account current subaddress tx <ArticMine> So 64 bytes for a typical tx <UkoeHB_> yeah basically <ArticMine> So if the security issue is verified I do not see an issue here <UkoeHB_> seddd, the base key must be generated by transaction authors <UkoeHB_> under the current construction, not sure if there are any other ways to do it <sarang> ArticMine: the math checks out on the fix <seddd>: Ok so unknowable ahead, gotcha <seddd>: will read more in the issue you linked <sarang> Probably time to bring it up in dev meeting again <UkoeHB_> seddd there might be something to that (using a fixed janus base key of some kind), Ill ponder it a bit <sarang> Any other action items to bring up? <seddd>: UkoeHB_ that's kind of what I was thinking, or a fixed set of usable bases <seddd>: Happy to collaborate, this is an interesting problem <sarang> for sure <sarang> OK, let's go ahead and wrap things up for this meeting; discussions can of course continue after we adjourn <sarang> Any last topics of general interest for the meeting? <sarang> Righto! Meeting adjourned <sarang> thanks to everyone for attending