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