| layout |
title |
tags |
author |
| post |
Logs for the MRL Meeting Held on 2020-03-25 |
| dev diaries |
| crypto |
| research |
|
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
