16:03:58 MRL meeting here in one hour. 16:59:26 👋 17:00:13 Meeting time: https://github.com/monero-project/meta/issues/928 17:00:22 1) Greetings 17:00:26 Howdy 17:00:35 Hello 17:00:52 Hello again 17:01:02 hi 17:01:12 hi 17:01:47 hi 17:02:14 2) Updates. What is everyone working on? 17:02:18 hello 17:02:24 Rucknium: the link on that Github issue for kayaba's alternate multisig implementation is the wrong link I believe 17:02:31 hi 17:02:36 me: Improved decoy selection with OSPEAD. 17:03:04 Oh you are right, jeffro256 17:03:21 Should be https://github.com/serai-dex/serai/blob/develop/coins/monero/src/wallet/send/multisig.rs 17:03:45 Thanks. Fixed 17:04:27 me: finalizing background sync, GUI implementation is nearly done 17:04:50 starting to plan for monerokon: https://kanban.monerokon.org 17:06:26 3) Discuss: How to confirm security of Monero's multisignature protocol? Do we need mathematical security proofs, and can we get them? 17:06:46 Outcomes could be: 1) Try to get a security proof for current C++ Monero multisig. 2) Get security proof for kayabanerve 's Rust implementation. 3) Do nothing and wait for Seraphis multisig implementation and security proofs. 4) Something else? 17:06:49 me: more serialization stuff; working on my convulted gpg setup; figuring out how to p2p-ssl tests (if at all) 17:07:27 I wrote some code which would allow `wallet2` to import/export part of its multisig info per onetime-address instead of everything all at once, which would help improve the scalability of syncing multisig info on multisig messaging systems 17:07:28 someone posted a security review by inference, did you see that rucknium? 17:07:48 Is weechat2 vtnerd? 17:07:54 ah crap, sorry 17:08:25 Security proof is different from security review of the code. My knowledge of this area is shallow, so maybe someone else can explain more. 17:08:45 it looked like a review of the code based on the report I saw (so they did both) 17:08:48 I believe the focus should be on ensuring Monero's security independent of my own work. Even if my work is proven secure, Monero still should ship a non-experimental multisig as a piece of core infra. Unless Monero is willing to ship monero-serai than... 17:09:06 vtnerd: Mind clarifying with a link, please? 17:09:18 *ship monero-serai, then... 17:09:23 https://community.rino.io/rino-multisig-pr8194-audit-20220627.pdf 17:09:31 rino paid for it, since it was part of their core business 17:09:37 Oh, the RINO audit 17:10:15 was that not good enough? They definitely looked at the code based on what I saw, but maybe this is untrusted for some reason? 17:11:01 rino paid for it, inference did the review 17:11:09 *or I assume rino paid 17:11:16 IIRC, that work explicitly says it's incomplete as it doesn't have a formal reference to verify against 17:11:39 I think we don't know if the math is right. Code can perfectly execute math, but if the math isn't right then the code is vulnerable. 17:13:01 kayabanerve : I don't remember seeing that listed in the report (that its incomplete) 17:13:08 Lack of math security proofs is blocking a lot of Monero development work. 17:13:21 For current C++ Monero multisig: I believe we would need security proofs (or at least formalized mathematical documentation of the protocol). Then probably a security review to verify the code matches up with that spec 17:13:21 The burning bug patch also wasn't included in the RINO audit. 17:13:25 It was UkoeHB who rewrote and improved large parts of the multisig code. I think to remember that he was *for* the experimental label quite strongly. 17:14:45 I don't see such a warning present, yet I have to note at no point in this audit does it comment on the protocol's security. It solely comments security against specific attacks. The warning I'm thinking of may have been human commentary associated with it not in the literal report... 17:15:06 (not that any audit should say the protocol is guaranteed to be secure, to say the audit isn't inclusive of the protocol) 17:15:44 > The client requested a review of this patch to the multisig system, in pull request #8149. The code was 17:15:44 reviewed at commit f5e33479d656bc95001d2f135651e9fe9194681a. 17:15:45 > We also assessed the three vulnerabilities the patch sought to address, looking at their security impact, 17:15:45 and the extent to which they have been adequately addressed by the changes in the patch 17:15:58 This is an extremely distinct scope from the multisig protocol and its implementation. 17:16:24 do you remember the name of the paper this was the musig code was based on? 17:17:36 MRL-0009 has the ECDH-based DKG and a three-round sign. Monero implemented the ECDH-based DKG to... some degree, which I can't comment, and a two-round sign. The current sign implementation is closest to Musig2. 17:18:20 I know Monero's DKG is the same premise. I'm not familiar enough to confirm it's the same protocol (or even that it attempts to be the same protocol). 17:18:38 https://www.getmonero.org/resources/research-lab/pubs/MRL-0009.pdf Brandon Goodell and Sarang Noether (2018) "Thring Signatures and their Applications to Spender-Ambiguous Digital Currencies" 17:19:45 kayabanerve since you implemented FROST (which already has security proofs) in monero-serai, would your impl need anything further spec'd for the Monero-specific parts? 17:20:00 Not to be a dick, but to be a dick, it would be immensely easier to prove the security of monero-serai AFAIK. Unfortunately, proving the security of monero-serai's multisig impl doesn't equal security for Monero's shipped multisig impl. 17:20:33 Why is that? Is it much simpler? 17:20:49 It's based on FROST, yeah? 17:21:13 oops already asked 17:21:32 Ok. So why not change Monero's shipped multisig implementation to a C++ version of your Rust implementation? 17:21:37 Ah, ok, "FROST (which already has security proofs)" 17:21:59 jberman: We don't have a custom DKG. We use PedPoP from the FROST paper. Accordingly, we don't need any security proofs reviewed. AFAIK, the ECDH-based DKG has proofs yet not reviewed proofs. Whether or not that needs its proofs reviewed, and whether or not Monero tries to impl that ECDH-based DKG protocol (or its own ECDH-based DKG protocol we handwave as close enough), I can't c omment. Please note RINO didn't audit that the DKG currently in Monero is equivalent to the one in MRL-0009. 17:22:53 As for the signing code, FROST itself is proven, with layers of review, and modular-frost is Serai's audited FROST implementation. Not only is it audited as a library (with, IMO, what I'd call praise from sarang), it's also compliant with the IETF draft. The IETF draft takes took the academic paper (which can be implemented in several ways) and created a literal spec to match. 17:22:54 That would make any already built multisig wallets invalid, right? 17:23:13 The Rust implementation has N^2 message passing complexity. Monero's C++ implementation has N! complexity (N factorial). That's another reason to switch to the Rust impl. 17:23:42 rbrunner: well, you could have both implementations in there, one legacy and one new. 17:23:51 There are many Monero-specific components in several ways. modular-frost then had a CLSAG algorithm written for it. While modular-frost ensures the integrity of the nonces, and the private key, and modular-frost was audited (meaning it does most of the heavy lifting), that doesn't change we have our own CLSAG algorithm floating around. 17:24:14 And then beyond the raw CLSAG algorithm, there's the entire TX construction code (though solely the CLSAG code could be integrated into Monero proper). 17:24:24 I remember reading the musig2 paper now, the code definitely was based on that (which has a security proof that needs reviewing?) 17:24:41 rbrunner: Technically, you could run a conversion protocol, but you shouldn't. 17:24:50 Technically, and correct me if I'm wrong, but I think you also only need O(N^2) messages, just that the size of the messages is N! 17:26:00 The original multisig implementation was flawed. That makes me wonder about the MRL-0009 paper. I haven't read the paper. It had a security proof against at least one type of attack, but I'm not sure if against all types of attacks. 17:26:22 vtnerd: The parts of Monero signing which needs proving/review/whatever is the CLSAG integration (as it requires one nonce BUT across two generators) *and* the key... interpolation? 17:26:40 rucknium, I recall the implementation being based on musig2 and not mrl009 17:26:47 Actually, there is no interpolation in the ECDH-based DKG. Accordingly, for Monero signing, the sole part up for discussion is the CLSAG-specifics and the DKG. 17:26:54 or maybe mrl009 is the same? Id have to look 17:28:10 I'll also note monero-serai implements *identifiable aborts*, and checks the data it's handed for propriety at each step. AFAIK, the Monero codebase doesn't have identifiable aborts and simply errors if the final signature fails. This creates vastly different DoS properties and may affect security analysis (as one may give you more leeway than the other). I'd ask koe to comment mo re before I make any final comments though. 17:28:32 Seems to be that before we can decide how to best move forward some research is needed: What is really implemented now in C++? 17:28:42 We also have a dedicated crate for building fiat-shamir transcripts, which was audite,d and does a lot of work with domain-separation, and minimize data sent around (minimizing opportunities to insert malicious data), etc, etc 17:29:37 Not to forget that we need a way to carry all this forward to Seraphis. I think multisig there is already implemented. 17:29:59 MRL-0009 is an ECDH-based DKG (and Monero also uses a ECDH-based DKG, I can't comment if they're intended to be the same) and a proven, Musig-DN-esque signing protocol. Monero's current is Musig2 inspired. 17:30:16 The audit did not confirm Monero's DKG is as specified in MRL-0009's, so even if they're intended to be equivalent, RINO's audit didn't cover that. 17:30:57 (and i keep going on about intent as we got into this issue with Drijver's in the first place because Monero didn't impl MRL-0009's Musig-DN-esque protocol yet a Musig-esque protocol) 17:33:12 What'd likely be easiest, in a pure-C++ way, is to explicitly intended Monero's DKG to match MRL-0009 (if not already) and have it audited to line up. Then, a Musig2-esque CLSAG should be formalized (likely a modification of MRL-0009's Musig-DN-esque CLSAG?) and Monero should explicitly intended to match it. The fact it lines up should be audited. 17:33:13 After that, we can claim we have a proven protocol implemented with the implementation audited. I believe that'd warrant removing the experimental label. 17:33:48 Can we for a change speculate a bit, if that's ok. What problems could there be in the current protocol, what bad things could happen? 17:34:09 I think people call this "failure modes" 17:34:41 It obviously works correctly, per se, as long as nobody starts an attack 17:34:49 I also personally believe extending FROST (which uses the same binomial nonces as Musig2) to CLSAG was natural and security of it should be considered trivially following. I have no practical doubts in its security. The one note is you have to publish your nonces across generators G *and* hash_to_point(K). I checked those nonces were correctly formed. Monero... may not have? And t hat part I don't like. if Monero does perform that check, I'd say the theory behind Monero's multisig signing being sane likely follows. 17:35:22 Since there's no identifiable aborts, a single malicious participant can potentially hold the protocol up ad infinitum as signers brute force all possible combinations of t over n until they find a multisig without the malicious signer(s). 17:36:07 The building of keys, or also the signing of transactions? 17:36:51 Signing. 17:36:51 If you have a 7-10 multisig, any 7 should be able to sign. If 3 are malicious, only a single combination will be valid. If you can't identify that combination, you have to brute force it. 17:36:52 kayabanerve: has there been any attempts at FFI for`multisig.rs` or monero-serai yet? i'm assuming cxx would be used? 17:37:01 7-10 combinations gets up there in possibility count... 17:37:54 It's still feasible. With multisig's at the size of Serai though, no, length of the universe esque bs. That's why we guarantee if there's a fault, one faulty participant will be kicked out, reverting it to being linear to the amount of malicious actors (not what I believe to be some factorial) 17:38:00 hinto: No 17:38:05 I don't understand. Isn't that trivial? I mean, if enough people are not in the mood to sign, everything comes to halt, no? 17:38:25 If there's 3 malicious, there are 7 who want to sign. 17:38:31 Well one participant could pretend they want to sign and submit bad data, and currently there's no way to figure out who dud 17:38:34 That's the threshold. The system shouldn't halt. 17:38:36 Those people would claim to cooperate, but do otherwise? 17:38:50 Right. 17:39:40 Any easy way to improve on that within the current C++ implementation? 17:40:02 Forcing it to a brute force of possible signing sets unless you have a identification protocol. AFAIK, Monero's protocol enables one and the Monero code simply doesn't calculate/report it. I'm also unsure how useful the blame would be in a round robin settings. If all that can happen is a single node files out an accusation, with no evidence, it's not useful. 17:40:33 So we'd need not only to have proper reporting, yet to be able to export a proof of blame. 17:40:34 In a FROST setting, there's no linear round robin. You simply send everyone every message while signing, and you don't need to tell people someone faulted. You just all detect if someone did. 17:41:02 Or we don't support identification, forcing the multisig to small-scale use cases which at worse become a game of Secret Hitler 17:41:31 hinto: here's a start at using cxx for integrating kayaba's full chain membership proofs into the monero repo: https://github.com/j-berman/monero/commit/722f266edd75e3ad521b01a9b6b92dae72c1ffa9 17:41:58 And how about any risks that somebody could steal funds that shouldn't be able to? 17:42:17 Suddenly somebody is able to sign alone, through some loophole 17:42:35 Not very probable, right? 17:43:04 In the signing protocol? That'd be via challenge manipulation or secret key leakage. 17:43:17 jberman: How will you do gitian builds? That's _a lot_ of transitive dependencies. 17:43:21 Challenge manipulation should be stopped via binomial nonces + higher level code. 17:43:32 (don't sign a raw hash you're handed, sign an intended tx you hash yourself) 17:44:00 tobtoht: Serai has in its repo reproducible builds of a wasm blob. 17:44:13 A wasm blob != monero-serai for x86. I'm just commenting we have a Docker setup to repro build Rust. 17:44:36 So there's a basis of work there.... 17:45:29 Whatever nice things can be said about that Serai multisig implementation, I somehow doubt that's the way to go. But well, not much more than a gut feeling 17:45:44 And this classic here, in a way: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ 17:46:17 I'll accept free audits as I'm not an idiot but I don't believe Monero should adopt monero-serai's impl. 17:46:18 Recently I have begun to think it is a mistake having multisig integrated in the core monero repo. I spent a ton of time working on multisig to get it perfect, and the end result is a lot of advanced code that realistically cannot be reviewed and maintained without a lot of resources. The core monero wallet should be designed to support custom wallet extensions, and multisig should go in a separate repo that can be 17:46:18 maintained (both dev work and security review/proofing) by those who depend on multisig. If we don't do that, multisig will end up an albatross blocking seraphis migration. 17:47:00 + identifiable aborts? Except those may be quite annoying in the round robin setting... 17:48:08 Actually, I don't believe we can have identifiable aborts *by key share* in the round robin setting because two people hold each key. We'd have to have add message authentication over every single message in the round robin protocol to obtain a single origin of a message (I don't assume that's already present?). 17:48:39 *in the ECDH setting 17:49:10 I do believe it's important for Monero to offer a canonical multisig, whether or not it's in a separate repository. 17:49:22 tobtoht: AFAICT zcash implements gitian reproducible builds using cxx + rust code integrated on their end as well. It doesn't look too bad on first glance 17:49:44 Yeah, to depend on those people "who need it" is maybe a tad optimistic 17:49:53 Are you saying that the current multisig implementation in the core repo needs round robin? AFAIK, there's no specific order nor signals to "pass" on the tx or submit disproval required for signin 17:50:18 No, the tx goes from one signer to the next 17:50:30 At least I don't know any other way to do it 17:51:06 jberman: Interesting, I'll have a look. 17:52:22 I'm saying because every key share is held by two people under the ECDH protocol, if a key share's contribution isn't valid, you can't identify a human at fault *because* two human had the key share. 17:52:57 I'm unsure the signing protocol's message format and if you can associate a human with specific contributions 17:53:11 Well, on the other hand I doubt that anybody seriously needs and seriously considers something like 7/10 17:53:39 ... i'm looking to support 101/150 :( 17:53:48 i'm right here rbrunner :( right here :( 17:53:52 and the combinatorial horror that ensues with people that try to sabotage 17:54:05 :P There are large-scale use cases is my point. 17:54:16 I guess you have a terrribly special use case for that? 17:54:52 Whether or not Monero wants to support them is a distinct issue, but I'd argue the current limit (16) likely needs to be significantly reduced. 17:55:05 I think, already, 16 isn't feasible for humans to bother with *and* it likely has to many combinations to not break under a few malicious actors. 17:56:16 If you think of the use case "Not a single person has all the XMR, but a handful of carefully selected people" you probably land at 2/4, or maybe 3/5 17:56:18 If Monero only wants to support up to 5 signers, I wouldn't object, as that lines up with most human use cases. 17:56:34 rbrunner: Decentralized network which receive coins on Monero. If we were only given 10 key shares, we could only have 10 validators. Not really too decentralized... 17:56:57 It's definitely special, yet it's not unique. THORChain currently claims their integration is blocked on technical reasons (including multisig being experimental). 17:57:18 Oh well, those people :) 17:57:20 Though I'm not asking Monero to support this use case. monero-serai exists for a reason. 17:57:40 What's the reason for not wanting Monero to adapt moner-serai? 17:57:47 This, and reducing the amount of supported signers to 5 or so, is my current advocacy. 17:58:18 To manage the CCS in the future, in particular? 17:58:30 jeffro256: I don't believe there's enough reason present in it to justify the Rust toolchain and dependency set. 17:59:08 rbrunner: 5 signers just sounds enough to manage most boards/CEX cold wallets/safety deposit backups/families. 17:59:17 Ah okay. And Ukoe is of the opinion to not have it in the core repo at all 17:59:22 have multisig 17:59:46 Monero already has an experimental multisig. Having it cross the line is feasible IMO, re: scope of remaining work. 17:59:55 Not sure re: developers willing to work on it. 18:00:55 Let's continue the meeting for at least 15 more minutes unless the main participants need to leave. 18:03:16 "What'd likely be easiest, in a pure-C++ way, is to explicitly intended Monero's DKG to match MRL-0009 (if not already) and have it audited to line up. Then, a Musig2-esque CLSAG should be formalized (likely a modification of MRL-0009's Musig-DN-esque CLSAG?) and Monero should explicitly intended to match it. The fact it lines up should be audited." 18:03:23 Do we know if identifiable aborts are possible to be added to future signing sessions while keeping key data backwards compatible? 18:03:42 ^ Do we think there are enough "internal + external resources to do this? Is it worth it? 18:04:44 Has MRL-0009 been peer reviewed? 18:05:32 jeffro256: If there's not a key actively associated with humans in the current protocol, then no, which I'd have to check. Regardless, my advocacy is reduced size multisigs, not identifiable aborts at this time (purely as a cost cutting measure) 18:06:56 Not AFAIK, though that's not on my list of requirements. 18:08:08 jberman: Only for x86_64 linux. https://github.com/zcash/gitian.sigs/tree/master 18:09:12 From my understanding, reproducible builds from x86_64 for other platforms aren't problematic. Reproducible builds from other platforms for a specific platform are. 18:09:38 I have a friend who ships a binary which must be reproducible and it can't be reproduced from ARM due to *host* platform effecting the target binary. 18:10:00 The difficulty is in setting up cross-compile toolchains. 18:10:03 I don't personally mind the comment "run docker in a x86-64 emulator to build for ARM" though. 18:10:20 Rust has *great* support for cross-compilation. 18:11:06 https://github.com/serai-dex/serai/blob/develop/orchestration/runtime/Dockerfile 18:11:06 Here's how we handle reproducible builds 18:11:53 We grab a specific Docker image, move to a Debian package snapshot, install deps, cross-compilation enabled via `rustup target add`, and then it's a very traditional build command. 18:13:07 ``` 18:13:08 rustup target add riscv32imac-unknown-none-elf 18:13:08 sudo apt update && sudo apt install -y gcc-riscv64-unknown-elf gcc-multilib 18:13:09 cd tests/no-std && CFLAGS=-I/usr/include cargo build --target riscv32imac-unknown-none-elf 18:13:09 ``` 18:13:10 And here's Serai code for RISC-V builds (not checking reproducibility) 18:13:18 Also, sorry, to clarify. Here's how *Serai* handles. 18:17:16 If anyone really wants to work on multisig, especially in the direction of kayabanerve 's proposal, please speak up. IMHO, this was a productive conversation, but I don't expect any action to be taken unless more labor it put toward the problem. Thanks everyone. 18:30:32 Rucknium: could you re-hash what kayabanerve's proposal was? I had a read through, but I'm a bit unclear. Quote "I'll accept free audits as I'm not an idiot but I don't believe Monero should adopt monero-serai's impl." 18:31:00 It's this quote. 18:31:24 Thanks! 18:38:40 Anyone working on a GUI for multisig (or planning to work on it)? 18:39:00 I am. 18:39:24 As part of Feather 18:41:26 see the discussion starting here: https://matrix.to/#/%23feather%3Amonero.social/%24TXNRqV1SRYfhVrIoovZ1RBRCIky6yRL6z7YRKTOald8?via=matrix.org&via=monero.social&via=frei.chat 19:27:39 Interesting, you mentioned "self-hostable message daemon", and I also found this post by jeffro256 : https://matrix.to/#/!LmpzSzbSMKFmPbCpHe:monero.social/$0QpDP_bexI6eLLQ49xIDZBExl7ESjLC1Zvf-n22VgSY?via=libera.chat&via=matrix.org&via=monero.social 19:27:39 I've been thinking about that as well - client-server architecture where client (GUI or CLI) is managing the keys and server (self-hosted) relays the messages to other participants.