05:51:20 Nice progress, @dangerousfreedom:matrix.org. Thanks for the report! 06:01:14 My PR (https://github.com/monero-project/monero/pull/10765) to implement Polyseed in the Monero core software inherits an important design / UX decision from @tobtoht:monero.social 's original patch: 06:01:46 To store any eventual (seed offset) passphrase together with the Polyseed, and return it again in info queries, and display it in the CLI wallet app together with the Polyseed. 06:02:00 Several important third-party wallet apps currently do it this way. 06:02:22 This review comment (https://github.com/monero-project/monero/pull/10765#discussion_r3410572998) from @jeffro256:monero.social shows me that this may be controversial and worthy of broader discussion. 06:02:45 I intend to submit it for discussion in today's Monero tech meeting; place and time see here: https://github.com/monero-project/meta/issues/1403 10:51:49 @rbrunner7: If you don't store it, you can't show a Polyseed to users if they set a passphrase. You have to downgrade to 25 words + restore height. 10:56:20 You would need to downgrade to 25 words immediately on wallet restore and not save the polyseed in the keys file. 11:35:00 Is that really the case? Isn't is possible to go from "polyseed_storage" again to a plaintext Polyseed without passphrase? Passphrase only comes into action if you have to actually derive private keys, as far as I remember. 11:36:04 Maybe there is a problem with encrypted Polyseeds however? 11:37:42 Probably will have to check the code again to be sure ... 17:02:46 Meeting in a bit less than 1 hour 18:00:02 Meeting time. Hello! https://github.com/monero-project/meta/issues/1403 18:00:07 hi 18:00:08 hi 18:00:08 Hello 18:00:10 Howdy 18:00:17 hi 18:00:27 Hey 18:01:11 waves 18:01:50 Ok, with those waves I think we are ready for the reports from the last 2 weeks. (There was no meeting last Monday because of Monerokon.) 18:02:05 worked on tests for the wallet-rpc based on Wallet API and got the only failing test multisig fail at a later stage now 18:02:24 @dangerousfreedom:matrix.org left a report in this room a bit less than 1 day ago. He made good progress and has FCMP++ running in Python as it seems. 18:02:52 Wrote some docs on seed encryption and wordlists, made a few different patches, I2P work, etc. 18:03:06 I myself could get the Polyseed PR out the door: https://github.com/monero-project/monero/pull/10765 18:03:34 v0.18.5.1, release date got moved up because of the p2pool vuln 18:04:04 How fast do we want to get this out? 18:04:05 I updated lws fcmp++ pr to newest lws and fcmp code 18:04:25 tobtoht: as soon as possible, of course not rushed 18:04:44 Hi, worked on multisig, reviewed jberman’s curve trees impl. Sneedlewood there may be overlap in the multisig issues we are facing. 18:05:05 we solved the windows GUI binary crash for stressnet (was an upstream issue), submitted the FCMP++ tree builder PR upstream, integration audit phase 1 should be complete soonish (working with Trail of Bits today on finalizing), reviewed jeffro's PR to speed up pool fetching (while testing found a separate issue in incremental [... too long, see https://mrelay.p2pool.observer/e/pN7Sr40LYTF2MlR5 ] 18:05:33 Quite a list ... 18:06:26 UkoeHB: I'm not on fcmp++ branch yet 18:07:34 me: worked on header compression and testing/review upstream PRs 18:08:34 Ok, if we are through with the reports already, I would like to open a first round of discussion regarding Polyseeds in connection with passphrases, as mentioned this morning UTC here and in -community 18:09:03 sneedlewoods: got it 18:09:42 I'm OK with not storing / showing the passphrase, if it is communicated to the user that they are responsible for remembering if it was used. 18:09:52 My PR has code and a "UX approach" inherited from a patch originally done by @tobtoht:monero.social : A passphrase that the user gives gets stored in the wallet.keys file, and the CLI wallet app seed command displays the passphrase together with the Polyseed 18:10:47 @tobtoht: As a one-time thing, right? 18:10:57 Every time the seed is shown. 18:11:01 There is an argument to do that as follows: If you use a (seed offset) passphrase with a legacy seed, and you display a seed using the CLI wallet command seed, you get everything needed to restore that wallet. 18:11:21 Is the same thing done for legacy seed offsets? 18:11:33 @tobtoht: Or, perhaps only during restore. 18:11:47 Why? Because the offsetted secret bits get translated to seed words 18:12:12 If you want to do the same, i.e. display everything needed for restore, with Polyseed, you have to display the passphrase 18:12:27 You can't turn the offsetted private key bits into a new Polyseed 18:13:34 But well, that's probably to discuss. Some people seem to want to hide the use of passphrases as much as possible, maybe even accepting differences between Polyseed UX and legacy seed UX when doing so 18:14:52 @jeffro256:monero.social made his position pretty clear already in a review comment, if I understood that correctly: Displaying the passphrase again undermines the very essence of them 18:15:58 For me, I have right now the same opinion as @tobtoht:monero.social regarding display: No strong preference, under the condition the user gets informed clearly. 18:16:18 Other opinions? 18:17:05 @rbrunner7: Under what threat model? The one where you're held at gunpoint and forced to open a wallet, you open a fake wallet with passphrase, which might give away that there is a real wallet with more funds. 18:17:26 Use a fake wallet without passphrase? 18:19:37 Or: someone could steal your computer, crack one of the wallets (with passphrase), which might reveal that another wallets exists and come back for more. 18:19:43 Use a stronger password? 18:19:44 A bit of info while we wait: Cake Wallet and Feather Wallet currently do show the passphrase when displaying a Polyseed if one was used 18:19:46 I mean, anything is possible to do. But accorsing to the standard, a bit is present in the Polyseed which determines whether or not the Polyseed is encrypted with a passphrase. So if the attacker is smart enough to know about offsets/passphrases, they could look at the seed and determine if it's an encrypted Polyseed or not 18:20:20 We're not using Polyseed encryption. 18:20:37 A little correction: My PR does not use Polyseed encryption on its own. It can restore, but does not produce. It uses good old seed offsetting, which is "invisible" 18:21:23 I'm less concerned about trying to mitigate coercion in this case, but trying to mitigate more run-of-the-mill data exfiltration attacks due to the seed not being encrypted at rest. 18:21:38 It's a little side question what you do when encountering an encrypted Polyseed when restoring: Insisting on the passphrase, or silently restore a "wrong" wallet 18:22:20 If i'm the kind of person to use a passphrase to encrypt my seed at rest, I expect the seed to be encrypted at rest, and to have to enter the passphrase to decrypt 18:22:34 @jeffro256:monero.social: Not sure I understand: Would that be a vote to use Polyseed encryption? 18:23:45 And not seed offsetting? 18:24:19 You'd rather have the encryption bit be present to give away the fact that you likely have a decoy wallet? 18:25:02 @rbrunner7:monero.social: Doing both would be a bit complicated for UX, but I don't see why not 18:25:20 @tobtoht: That's a Polyseed thing, not a Monero thing 18:25:21 You mean give the option at wallet creation? 18:25:53 @jeffro256: I know. I'm saying that's a bad design decision. 18:26:16 A seed should never reveal if a passphrase was used. 18:26:30 Ok, anyway, with this we have two questions open already: Whether to "encrypt at rest", and whether displaying passphrases again 18:26:35 I'd rather reject Polyseeds with encrypted passphrases than to siliently do them completely wrong and store them without passphrases 18:27:11 @tobtoht: I'm also agree, I think that the passphrase bit was not a great idea. 18:27:15 If we reject encrypted Polyseeds, you can' restore Cake wallet seeds that used a passphrase. A bit unfortunate ... 18:27:50 *you can't 18:29:10 Seems to me we have some hard facts that we can't fully avoid. Polyseed encryption and feature bits are as they are, and Cake Wallet uses that. 18:29:34 So we probably search for the least evil now. 18:30:36 Another thing: If we drop that passphrase storage in account now in the core software, we more or less force all third-party wallets that use the monero_c library to give up passphrase display. Which the devs of those apps may or may not like. 18:31:15 We could of course to continue to store, but not display with the seed command. 18:32:02 @rbrunner7: What is the point of displaying the passphrase again? 18:32:10 And swallow the toad of having a wipeable_string serialization :) 18:32:12 It seems as if legacy seeds currently do not show the offset passphrase after being restored. Is this correct? 18:32:24 @jeffro256: Without it you can't restore the same wallet. 18:32:30 To display everything that is needed to restore the wallet, as it's the case with legacy seeds, even if they use a passphrase. 18:32:54 Symmetric UX. 18:33:00 @tobtoht: Yes, but isn't the point of the passphrase not being in Polyseed that you user has to remember it?? 18:33:03 @jpk68:matrix.org: AFAIK they show a new legacy seed 18:33:21 Why encrypt something if you provide the encryption keys right next to the ciphertext ? 18:33:22 A dummy passphrase field may be useful to prevent (future) .key file incompatibilities with wallets that used the patch. 18:33:23 and no passphrase 18:33:45 But wouldn't the exact same thing happen with Polyseed offsets? It would just restore an 'incorrect' wallet with no passphrase? 18:34:01 @sneedlewoods_xmr:matrix.org: Exactly. And that "new" legacy restores you the same wallet, without passphrase. 18:34:06 it does restore the correct wallet though 18:34:11 with legacy 18:34:22 Ah, I see. Thanks 18:34:35 Yes. And with Polyseed without passphrase, you get the wrong wallet. 18:35:14 But well, as I said, with some info on screen you can probably get away with that UX difference. And I think we do expect people to remember passphrases themselves. 18:36:00 and if they forget they can still show their ssk and restore from there, just without Polyseed features!? 18:36:14 @tobtoht:monero.social: Not sure whether a "dummy" passphrase would be enough. If the apps cannot query it, they can't display a passphrase if they so want. 18:36:54 Yes, there is a new CLI wallet legacy_seed command that gives you exactly that legacy seed. 18:37:06 Here's how I would see the UX flow going: user w/ encrypted Polyseed asks for seed, wallet SW seeds that Polyseed is encrypted, wallet SW asks user for passphrase, user gives it, wallet validates password and shows original, encrypted Polyseed phrase 18:37:10 Passphrase stays in the user's head 18:37:52 @rbrunner7: Then I don't see a problem in not showing the passphrase and inform the user to keep track of it. 18:38:04 wallet2 uses a password for in-memory encryption, and needs it for ops which require a decrypted spend key. For UX purposes, that password could be the same as the Polyseed password 18:38:54 That's now a confusing amount of possible ways to do it 18:39:31 I think an important point is how much weight people give the argument of "encryption at rest" which is not given with the PR right now 18:39:49 @jeffro256: this UX makes sense to me as well. I find it strange the legacy seed UX displays a different seed than the one the user has already written down / was supposed to write down 18:39:58 I never liked that my polyseed wallets show the passphrase next to the seed. The argument is that, if they have access to your wallet where they can access the seed, they already have access to the spend and vjew keys anyway 18:40:35 @jberman: This always confused me, and i still dont know which seed im supposed to use when restoring 18:40:57 And whether with or without offsest, right? :) 18:41:34 But that's legacy. Looking forward, it would be nice to arrive at some loose consensus how to do it properly with Polyseeds. 18:43:10 A compromise could be, as I seed it: A) Not using Polyseed encryption, because that gives the passphrase use away, B) continue to store, in the interest of third party devs who have strong opinion to (continue to) display passphrases, but C) NOT displaying passphrases in our UI 18:43:42 @ofrnxmr: Except that if it was implemented correctly, they wouldn't because they have the encrypted seed phrase, not the real key material used to derive the spend key 18:44:11 But those wallets happily show you the keys, no? 18:44:15 The raw keys 18:44:17 If they have the encrypted seed phrase and you have a weak password, then yeah, you're cooked. 18:44:25 @rbrunner7: yep 18:44:45 at least for legacy seed and if restored by key 18:44:57 I don't think you can drop raw key material display altogether 18:45:05 I prefer C, if only because i dont like to see my passwords in plain text unless i am typing them 18:45:31 Well, my proposal has 3 parts, all implemented A) and B) and C) 18:46:15 Maybe I should also mention D) sadly, no "encryption at rest" is implemented for Polyseeds 18:46:30 @rbrunner7: wallet2 needs a passphrase though of some sort if your wallet2 file has a password because the keys are encrypted in-memory. So while at rest, even if someone dumped your while memory, they theoretically can't get your raw keys w/o your passphrase 18:46:31 because of complicated and interplaying requirements 18:47:45 So yes, displaying raw key material is an action, but it requires further knowledge from the user. This is how Polyseed passphrases should be handled. 18:47:50 Correct, of course. I was talking about wallet UIs. I don't think you can only ever display seeds there, and hide raw key values completely from users. They may need raw keys. 18:48:08 You necessarily store the spend keys, so you might as well store the passphrase for better UX. Unless you're concerned about information leaks. Which you can defend against as I pointed out earlier. 18:48:14 Wallet password != polyseed passphrase 18:49:02 Wallet password as Polyseed passphrase would be quite a serious deviation from current legacy seed UX 18:49:12 and one where I don't see tangible benefits right now 18:49:20 @tobtoht: You necessarily store them encrypted, there's a difference 18:49:34 You would store the passphrase encrypted as well? 18:50:03 It's part of the account, which gets encrypted with the wallet password, like everything else 18:50:24 I wouldn't store the passphrase, period, just like how you don't store the wallet2 passphrase in-memory, because that would defeat the purpose of the in-memory encryption 18:51:04 The wallet2 password, you mean? 18:52:02 @jeffro256:monero.social: How do you weight the argument that with this, we force the hand of all third-party devs that use monero_c ? 18:52:05 A user probably shouldn't need both their wallet passphrase and seed passphrase to open their wallet / spend, and a user probably shouldn't use the same wallet passphrase and seed passphrase 18:52:42 I don't think that's on the table as proposal? 18:52:46 (nit: wallet password. seed passphrase.) 18:53:14 So it makes sense to be able to arrive at a spend key in an already created wallet without needing the seed passphrase 18:54:17 Not sure I understand. How would that not be case? 18:54:25 @jberman: I disagree. Obviously, when it really gets down to it, it is subjective. But if explicitly add a passphrase to my seed, I expect it to be encrypted with that passphrase... 18:54:54 *But if I 18:55:26 @jeffro256:monero.social: If only there wasn't the tradeoff to give passphrase use away that way. 18:55:41 @rbrunner7: it means we'd either need to store the seed passphrase, or the actual spend key somewhere that can be arrived at with just wallet password. Aka probably would make sense to store seed passphrase to achieve that UX 18:55:46 @rbrunner7: to be frank, it shouldn't be the core repo's problem when downstream jumps the gun and implements something incorrectly without trying to upstream it > <@rbrunner7> @jeffro256:monero.social: How do you weight the argument that with this, we force the hand of all third-party devs that use monero_c ? 18:55:47 Which is unfortunate, but as I said, Polyseed is as it is 18:56:59 The actual spend key is always at hand after you gave the wallet password? 18:57:29 @jeffro256: my view of the benefit of a seed passphrase is that if someone finds your seed copy somewhere laying around, you have extra protection from the seed passphrase. It's not for in-memory protection / not an expected UX to have to re-input seed passphrase all the time 18:58:34 Yeah, right, was also thinking along that line, but then you can trivially store 2 halves of your seed in two different places ... 19:00:19 That wouldn't make it a decoy wallet. 19:00:20 @jberman: I definitely think that that was the primary intended purpose. I'd be willing to accept that the spendkey and original-passphase-encrypted Polyseed only stays encrypted with the wallet2 password while in-memory. But the passphrase absolutely, positively should not be stored in account keys inside the file 19:00:29 @tobtoht: It would obviously be "half a seed" 19:00:49 Well, as I said, without drastic measures like forking Polyseed to Polyseed++ without encryption feature bit and overruling tevador's design "encyption at rest" will always have the unfortunate "feature" of giving the passphrase use away. 19:01:32 Which people may find worse than having encryption at rest - or not having that? You know what I mean. 19:04:29 Wallets who do want to continue to display passphrases have the option to do it using a wallet "attribute". There just would be no upgrade path for wallets written by monero_c that I can how to implement. 19:04:45 *that I can see how to implement 19:05:46 Alright, we might get some more votes later this week from people who read this. 19:06:04 Any more arguments and votes right now about this? 19:07:30 If not, anything else to discuss right now? 19:07:38 What about the lgpl license? 19:07:54 I don't know much about how that license works tbh 19:08:05 What is LPGL? Polyseed? 19:08:10 Yes 19:08:17 https://github.com/tevador/polyseed/blob/master/LICENSE 19:08:19 Appear so 19:08:30 Uff... 19:09:02 No idea, really. 19:09:25 I think it works, but then monerod becomes defacto lgpl when compiled in 19:09:38 Taken to the extreme, could this prevent using Polyseed in any other form than dynmic lib / DLL? 19:09:58 *dynamic lib 19:10:17 Not an option. 19:10:46 Is that another license, that with the DLL option? 19:10:51 We must statically link for release binaries. 19:11:09 Ah, you mean that's not something we can technically do. 19:11:29 This might be helpful: https://licensecheck.io/blog/lgpl-dynamic-linking 19:12:29 That's a whole new can of worms. Did everybody using Polyseed so far just ... well ... glance over this? 19:12:42 According to this website, the core repo already fits the criteria for static linking with Polyseed 19:13:22 We would need to add a license command to CLI to show the copyright notice though I think? 19:14:07 I would be very grateful if somebody in the know here (which currently is not me) could research a bit here and then report back 19:14:11 I don't know about Cake 19:14:29 @tobtoht: I believe so 19:14:56 yeah it looks fine because most wallets are providing 100% source anyway 19:14:57 Or we could ask tevador to consider relicensing? 19:15:12 so it meets the “relinking” portion since the source is provided 19:15:55 How would such a "license" command look? Would it need to provide the whole text of the license? 19:16:01 but someone attempting a closed source app “on top” of monero wallets would have to disable/remove polyseed or provide re-linking capability 19:16:30 Good luck with that :) 19:16:56 @tobtoht: The only copyrightable contributions are from tevador. 19:18:07 It's unfortunately late to stumble over this problem 19:18:56 Is everything else that we compile in really MIT license? 19:19:06 Did anybody check that already? 19:19:47 I vaguely remember rapidjson not even being free software because of some weird clause in its license. 19:19:57 Splendid 19:20:37 Ok, I guess we have to leave this as pending for the moment. 19:20:38 We have to replace it eventually anyway given it's unmaintained. 19:20:49 tevador put mx25519 under the same license BTW 19:21:06 Which we also use? 19:21:11 So we would need to sort that out before FCMP++ 19:21:26 mx25519 is used in the CARROT code 19:21:34 And that's considerably newer than Polyseed? 19:22:05 Which could mean that Tevador really likes it that way? 19:22:05 Initial commit was August 2022 19:22:36