monero-site/_posts/2020-03-25-mrl-meeting.md

142 lines
9 KiB
Markdown
Raw Normal View History

---
layout: post
title: Logs for the MRL Meeting Held on 2020-03-25
tags: [dev diaries, crypto, research]
author: asymptotically / Sarang
---
# Logs
**\<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