08:32:39 <br-m> <tobtoht> For what it's worth: Electrum (Bitcoin) shows both the seed and passphrase.
08:48:07 <br-m> <tobtoht> I was thinking of https://wiki.debian.org/qa.debian.org/jsonevil which only affects a subcomponent of rapidjson that we don't use. This got clarified over a decade ago: https://github.com/Tencent/rapidjson/issues/377 > <@tobtoht> I vaguely remember rapidjson not even being free software because of some weird clause in its license.
08:52:10 <br-m> <rbrunner7> "For what it's worth: Electrum (Bitcoin) shows both the seed and passphrase." Interesting, but I suspect that won't sway opinions here for the particular case of Monero.
13:59:09 <br-m> <jpk68:matrix.org> I mean, it would be a much cleaner solution > <@tobtoht> Or we could ask tevador to consider relicensing?
14:10:46 <br-m> <jpk68:matrix.org> To my understanding, if we are distributing statically-linked release binaries, all software downloads either have to have the full source code included with the binary, or downloads for the code have to be placed directly next to the binaries. Plus the license notice, as vtnerd mentioned
14:11:47 <br-m> <jpk68:matrix.org> GPL and the like impose an insane number of requirements that will just make everything needlessly complicated
14:23:13 <br-m> <tobtoht> The information leak also exists if you only show the Polyseed. If the Polyseed alone doesn't restore the same wallet, an attacker can determine that a passphrase was used.
14:27:54 <br-m> <tobtoht> To avoid the leak, downgrade to 25 words on restore. However, after Polyseed becomes the default using 25 words itself might raise suspicion.
14:29:55 <br-m> <tobtoht> We can ask higher effort from people with higher threat models. You can work around the information leak, so we shouldn't go out of our way to have it not exist at the cost of worse UX.
16:00:17 <br-m> <jpk68:matrix.org> @rbrunner7:monero.social I did end up finishing a small docs writeup for seed wordlists and encryption. If you're interested, it could probably use some fact-checking :)
16:00:22 <br-m> <jpk68:matrix.org> https://paste.debian.net/hidden/5fdf5f74
16:00:53 <br-m> <jpk68:matrix.org> I realize the Polyseed encryption thing is likely a bit inaccurate; maybe it can wait for now
16:04:38 <br-m> <tobtoht> @jpk68:matrix.org: link dead?
16:05:05 <br-m> <tobtoht> nvm
16:05:06 <br-m> <jpk68:matrix.org> If it says 'paste not found' then it just doesn't like your IP
16:05:29 <br-m> <tobtoht> I had to request a new circuit a few times
16:10:17 <br-m> <tobtoht> Passphrases are perhaps better understood as "seed extensions". The mnemonic seed itself is never "encrypted".
16:13:41 <br-m> <tobtoht> You extend the seed with extra words. Not: encrypt the seed with a passphrase. The latter implies you obtain a new seed which requires a passphrase to unlock.
16:14:44 <br-m> <jpk68:matrix.org> I just used the word 'encrypted' since that's what's used in the CLI wallet (encrypted_seed)
16:16:22 <br-m> <jpk68:matrix.org> My thought process was that 'encrypted' sort of meant the same thing as 'obfuscated' here, as the passphrase is applied to the curve point when restoring from the regular seed and passphrase. But yeah, your point makes sense
16:17:20 <br-m> <tobtoht> (Aside: This is another reason to remove translations (for now). Until we agree on the meaning of words and construct a glossary, the translations are wrong and do more harm than good.)
16:53:10 <nioc> I will ask a silly question.  What is the purpose of polyseed?
16:54:02 <nioc> is it only to save the restore height for restoring from seed? 
16:55:26 <br-m> <jpk68:matrix.org> It's also 36% shorter
16:55:28 <br-m> <tobtoht> Its raison d'etre is to improve seed UX in two ways: embedded creation date, fewer words to write down. (IMO BIP39 also has higher quality wordlists.)
16:57:10 <br-m> <rbrunner7> I think at least in theory you could restore a single missing (or wrong?) word from the info in the checksum
16:57:25 <br-m> <tobtoht> Oh, that too!
16:57:45 <br-m> <tobtoht> https://docs.featherwallet.org/guides/damaged-seed
16:58:06 <br-m> <rbrunner7> Ah, yes, you even offer something in this regard in Feather
17:12:55 <nioc> could the process for recovering damaged seeds be made for legacy seeds?
17:12:56 <br-m> <rbrunner7> I have a question for @vtnerd:monero.social , @jeffro256:monero.social , or anybody else with deep knowledge about the way our KV serialization works:
17:13:11 <br-m> <tobtoht> Polyseed will allow you to restore a single missing word. If you have an address associated with the wallet you can bruteforce 3 maybe 4 words in a reasonable amount of time. This also works for legacy seeds (and is available in Feather).
17:16:19 <nioc> so you need to write down your seed and passphrase if you use that but it allows you to not write down your creation date
17:16:21 <nioc> hmmmm
17:16:53 <br-m> <tobtoht> you don't need to write down your passphrase, that's the point of passphrases, to not write them down. :)
17:20:56 <br-m> <tobtoht> of course, you could write down the passphrase and store is in a different location if you don't want to rely on your memory. valid but different threat model.
17:22:08 <nioc> you can also memorize a 25 word seed  :)
17:24:11 <nioc> anyway I assume we need to accommodate many use cases 
17:24:36 <nioc> thx everyone
17:24:44 <br-m> <jpk68:matrix.org> You can always keep using the regular ones after the switch
17:25:18 <br-m> <rbrunner7> Sure, and even flee Polyseed and switch to a legacy seed instead, if you try and are not convinced
17:26:23 <br-m> <rbrunner7> Ok, now to my serialization question:
17:26:42 <br-m> <rbrunner7> Wallets that use parts of this code already through monero_c store the passphrase as a member m_passphrase of the account_keys class.
17:26:51 <br-m> <rbrunner7> It's done by making wipeable_string serializable, and include m_passphrase in the serialization of account_keys. Relevant code:
17:27:00 <br-m> <rbrunner7> https://github.com/rbrunner7/monero/blob/b935b987366901600aac6914a2f9e2d0f36c1fc4/src/cryptonote_basic/account.h#L78
17:27:10 <br-m> <rbrunner7> https://github.com/rbrunner7/monero/blob/b935b987366901600aac6914a2f9e2d0f36c1fc4/contrib/epee/include/wipeable_string.h#L79
17:27:25 <br-m> <rbrunner7> Now, say I want to do the following: Not store the passphrase in this way in the Monero core Polyseed support code, but offer those wallet apps a reasonable upgrade path should they want to continue to display the passphrase.
17:27:35 <br-m> <rbrunner7> I imagine to remove m_passphrase, introduce a new m_legacy_passphrase member of account_keys, and serialize that in a way that is less, well, strange than making 'wipeable_stringserializable, while staying byte-for-byte compatible with existing wallets that usedm_passphrase` to serialize.
17:27:43 <br-m> <rbrunner7> How to do that? In a similar way to how multisig_keys are serialized in a quite special way in account_keys? Would using std::vector<char> and some magic to store m_legacy_passphrase under a key of m_passphrase already be all that is needed?
17:29:32 <br-m> <tobtoht> Not important to your question, but including legacy in the variable name might cause confusion with legacy seeds?
17:31:28 <br-m> <rbrunner7> Well, anything that makes quite clear that this is not the "normal" core code way to do it will do. And that makes clear it's not meant for regular use, but as a migration facility - those wallet apps should switch to store the passphrase as a wallet attribute, like Feather and Cake do.
17:32:02 <br-m> <rbrunner7> We just don't silently drop the data, that's the idea.
17:33:16 <br-m> <rbrunner7> Maybe simply m_old_passphrase ...
17:33:43 <br-m> <rbrunner7> We will find something :)
17:33:51 <br-m> <rbrunner7> If we do want to go down this route
17:34:24 <br-m> <tobtoht> Having the Polyseed in .keys and the passphrase in the cache will cause some unexpected behavior if the cache is reset. To migitate that, wallets using monero_c could check if the stored polyseed derives the secret spend key and inform the user if it doesn't.
17:35:24 <br-m> <tobtoht> this could be added to the API? was_passphrase_used
17:35:43 <br-m> <rbrunner7> Does that happen in smartphone wallet apps? Do they also sometimes reset the cache?
17:36:02 <br-m> <tobtoht> Cache corruptions used to happen all the time. I don't know what the current state of affairs is.
17:36:14 <br-m> <rbrunner7> I see.
17:36:36 <br-m> <vtnerd> I’m not sure what you’re asking @rbrunner7:monero.social. there’s a is_store variable that can be used to do different logic when loading vs storing
17:36:50 <br-m> <vtnerd> you can also create distinct load and store functions
17:37:47 <br-m> <rbrunner7> Yes, if I look at the code for dealing with the multisig keys I get some hints how that works. Just asking for the best i.e. simplest way.
17:38:26 <br-m> <rbrunner7> If wipeable_string is basically std::vector<char>, are the serializations of those two compatible?
17:39:30 <br-m> <vtnerd> not in the way you have it currently.
17:39:32 <br-m> <rbrunner7> Ah, maybe not, because it's "one level deeper"
17:41:20 <br-m> <vtnerd> in your current PR, its serialized as {“buffer”:}
17:41:26 <br-m> <vtnerd> crap that idn’t display right
17:41:44 <br-m> <vtnerd> object{“buffer”:{string}}
17:42:09 <br-m> <vtnerd> basically you created an object wrapper around wipeable_string
17:49:26 <br-m> <rbrunner7> I could create a small helper class with the absolute minimum copied from now serializable wipeable_string to do it a compatible way. Although that's not pretty.
17:51:45 <br-m> <rbrunner7> @jeffro256:monero.social 's review comment when seeing that wipeable_string serialization: "Pleeeeeease no"  :)
17:52:07 <br-m> <rbrunner7> In a way, I understand him.
18:17:31 <moneromooo> Why might you want to serialize a wipeable_string...
18:18:35 <moneromooo> Ah, you need to ask RPC for a seed or something :/
18:20:28 <br-m> <jeffro256> Wipeable strings should never be implicitly serializable IMO. That's how you get the wallet casually dumping view keys to the log files, which I fixed in this PR: https://github.com/monero-project/monero/pull/9450
18:21:20 <br-m> <jeffro256> If you have an application which requires serializing wipeable strings, do it explictly at the call site 
18:40:07 <br-m> <rbrunner7> I agree. Just checking whether there is a reasonable and sensible way to not let those monero_c based wallets stand completely out in the rain.