00:00:11 <derbleak> I like the idea of making the index deterministic
00:00:45 <knaccc> sweet. i'm thinking that'll help a little with the view-only wallet balances
00:01:40 <derbleak> what about removing tx creator control of indexes altogether? would deterministic indexing achieve that?
00:01:43 <knaccc> i'm not sure if it's necessary, but maybe also concatenate real_index_seed as part of the change_tag hash, as a sanity-check on whether the tx constructor pledged to choose real indices deterministically
00:02:22 <knaccc> derbleak i'd be interested if you could figure out how to let the outside world check that without disclosing the real indices
00:02:39 <derbleak> zkp to the rescue :)
00:02:57 <derbleak> mb even just pedersen commitments
00:03:00 <derbleak> idk
00:03:56 <knaccc> btw i was looking at your 454.pdf earlier. i don't understand the math, but what an awesome achievement
00:04:27 <derbleak> right 0.0 still reading through it
00:04:35 <derbleak> so excite
00:05:16 <knaccc> is that borat or doggolingo
00:05:25 <derbleak> lol
00:05:36 <derbleak> upick
00:06:17 <knaccc> i'll err on the side of doge, since borat would say "i very excite"
00:20:50 <sarang> knaccc: you can't check that though, right?
00:20:59 <sarang> Whereas the deterministic scalar method _can_ be checked
00:21:09 <sarang> (but a wallet not doing it will be missed)
00:39:46 <knaccc> sarang right, you can't check that the sender isn't someone who has stolen your private view key and is lying, and you can't verify there wasn't a bug in their wallet software. so this is purely to make view-only wallet balances more useful than they currently are, with the proviso that you should always use key images to verify funds have not been stolen and that the view-only balance is correct
00:41:35 <knaccc> i'm trying to not let the perfect be the enemy of the good, since there is no verification or storage cost to making the real index deterministic
00:41:55 <sarang> No, I mean that the deterministic index is unreliable
00:42:02 <sarang> in a way that deterministic _scalars_ are not
00:42:23 <knaccc> i think perhaps i don't understand what you mean by deterministic scalars
00:42:35 <knaccc> i thought you were referring to the change_tag stuff
00:44:06 <knaccc> i.e. that you can verify the commitments match your alternatively-encrypted ecdhinfo amount
00:50:24 <UkoeHB_> How would you define the order for ring membership? Afaik right now the order is just member age
00:53:15 <knaccc> interesting, i'd  assumed they were currently shuffled randomly
00:54:03 <knaccc> i guess actually they were never shuffled randomly right? due to the way indices are encoded
00:54:31 <knaccc> yeah that's a good question.
00:55:47 <moneromooo> The order within a ring is blockchain order. Delta encoded. There's no point in shuffling them really, is there ?
00:55:49 <knaccc> i think you'd have to decide the real indices first, then choose the decoys such that the output global indices are such that they do order correctly
00:56:01 <knaccc> moneromooo right yes the delta encoding
00:56:18 <moneromooo> That's... a point for shuffling ?
00:56:38 <knaccc> i'm agreeing that the delta encoding prevents shuffling
00:56:55 <knaccc> and therefore you'd have to choose the decoys such that the intended real indices work out
00:57:05 <moneromooo> Well, doesn't really. It just is the smallest way to encode it (in the general case).
00:57:26 <knaccc> yeah i'm assuming we wouldn't want to mess with the compactness of the delta scheme
00:57:36 <knaccc> or have to invent negative varints
00:57:51 <moneromooo> They can use the same system.
00:58:16 <moneromooo> MRL had been talking for a while about deterministic picks, so that you wouldn't encode the offets, just a seed which could generate them.
00:58:42 <moneromooo> I think one of Matthew Green's students actually made an actual test of this.
00:59:16 <knaccc> interesting, i am in favor of deterministic decoy selection
01:00:03 <knaccc> i guess the method that they'd come up with involved brute forcing an IV until the scatter included your real input in the selection of outputs?
01:00:56 <moneromooo> Might take a long time for old outs. You could also include an offset. You generate once, then include an offset such that one of the generated outs matches your input.
01:01:20 <knaccc> oh yes, that's a much better idea
01:01:20 <moneromooo> I'm unsure whether that offset would leak anything.
01:01:55 <moneromooo> The offset thing will likely skew the distribution, so *some* amount of brute forcing will likely be wanted anyway.
01:02:12 <knaccc> in that case, it's pretty easy to choose the offset such that you end up with your real input in the position you deterministically want it to be in
01:04:35 <derbleak> imho, removing the offset entirely would be ideal (via deterministic decoys or w/e)
01:04:48 <knaccc> what is w/e?
01:04:56 <derbleak> whatever
01:05:33 <derbleak> whatever means work + meet design reqs
01:05:56 <knaccc> i'd image brute forcing isn't a significant computation compared to the EC ops that also need to be done to construct a tx
01:06:23 <derbleak> EC ops are more cryptographically sound
01:06:54 <derbleak> some cryptographic method of generating decoys is preferable, imho
01:07:16 <knaccc> hashes count as a cryptographic method, and those are very lightweight compared to EC ops
01:07:44 <derbleak> where is the bruteforcing involved with hashes in this context?
01:09:13 <knaccc> i'm assuming the scattershot that would need to have an IV brute forced to ensure the scatter contained your intended real input in the correct position in the scatter would be hash based
01:09:42 <knaccc> this is just about decoy selection, EC ops should never need to come into it
01:09:56 <derbleak> why not make the index a hash(pubkey | input | w/e)?
01:11:07 <knaccc> i'm sure constructs like that will go into the more complex task of determining a good scatter of decoys
01:11:18 <derbleak> then receiver search for index matching hash(signing/view pubkey | input | ... )
01:15:24 <gingeropolous> ironically larger ringsizes might reduce the amount of bruteforcing required
01:16:34 <gingeropolous> if you have to align 1024 points across the blockchain, the offsets / transform could be smaller. or at least they might get to optimal quicker. basically there's less space to search
01:24:53 <knaccc> great point
03:01:42 <sarang> The method suggested by Green's student doesn't play nicely with the more complex distribution we use
03:01:53 <sarang> But it's a hashed shuffle with an offset
03:04:03 <sarang> You need a transform from uniform selection to the desired distribution
03:44:06 <derbleak> potentially relevant: https://fastd.readthedocs.io/en/v18/crypto/fhmqvc.html
03:44:50 <derbleak> mentions use of TLV for auth tags
03:46:04 <derbleak> similar to one of the points discussed in monero/6456
03:46:54 <derbleak> (implicit PFS is a big win)
14:13:26 <sarang> Hello all
14:59:13 <Inge-> hi
15:03:54 <UkoeHB_> good monrign
15:09:07 <Inge-> Anyone heard from Surae ?
15:10:35 <sarang> I chatted with him a couple of days ago, briefly
15:21:53 <Inge-> I'll take that as a positive sign.
18:38:33 <sarang> New PR to fix up in-memory key encryption: https://github.com/monero-project/monero/pull/6474
18:38:36 <sarang> Review requested
18:55:31 <sarang> So I'm considering the implications of adding message authentication to encrypted files within the ecosystem, after a suggestion was presented about this
18:56:13 <sarang> Any particular downsides to this?
18:57:10 <sarang> I'm considering how an adversary might remove the authentication tag and trick the user into simply performing non-authenticated decryption, which is what would need to happen to older files before they could be transitioned over
18:57:20 <sarang> If that happens, the authentication is useless
19:02:10 <UkoeHB_> examples of encrypted files that would need to transition?
19:06:30 <sarang> e.g. ringdb information
19:06:37 <sarang> and e.g. https://github.com/monero-project/monero/blob/master/src/wallet/message_store.cpp#L692
19:10:23 <sarang> Since key derivation is different between plain-old ChaCha20 and ChaCha20-Poly1305, the risk may be low
20:28:05 <derpy_bridge> <[keybase] unseddd>: an attacker tricking a user to use an old client to perform decryption sans MAC is no worse than the current situation
20:28:48 <UkoeHB_> although a user who believes MAC would protect them, might be mistaken
20:29:12 <sarang> correct
20:33:57 <derpy_bridge> <[keybase] unseddd>: a user being tricked to use an old client to decrypt wallet files has more problems than MACs
20:34:35 <sarang> It's not about an old client necessarily. It's that old files legitimately have no MAC
20:34:53 <sarang> and need to be decrypted successfully in order to transition to a MAC construction
20:35:56 <sarang> However, using the chacha20-poly1305 keying protocol means that falling back to the chacha20 keying in the absence of a poly1305 tag would not attempt to decrypt a malicious file with the expected key anyway
20:36:09 <sarang> and therefore may not be a problem
20:38:02 <derpy_bridge> <[keybase] unseddd>: not necessarily, a non-standard key derivation could be used to gen the Poly1305 key, and compute a MAC over the current ciphertext (not sure it adds any security if wallet is considered compromised)
20:40:54 <derpy_bridge> <[keybase] unseddd>: if Poly1305 is rolled out for wallets, users could be advised of the potential chosen-ciphertext attack on previous wallet files, and encouraged to regen from seed using the new encryption
20:41:44 <derpy_bridge> <[keybase] unseddd>: obviously not as workable to start from scratch with everything, but maybe for the ultra-paranoid
20:44:49 <derpy_bridge> <[keybase] unseddd>: the attacker window is also pretty small, only has one chance post-upgrade: user has chacha20 wallet - (potential cca) - user decrypts wallet - user encrypts using standard ChaCha20Poly1305
21:03:42 <sarang> Yes. I mean that I don't consider there to be a risk of a downgrade attack
21:04:11 <sarang> That is, CCA for an attacker who takes a post-poly wallet and tries to downgrade by stripping out the tag
21:07:56 <derpy_bridge> <[keybase] unseddd>: tangent: have a stable fuzz test running! will PR after letting it run a bit longer
21:08:13 <derpy_bridge> <[keybase] unseddd>: ^ for CLSAG
21:08:57 <sarang> neat
21:09:37 <derpy_bridge> <[keybase] unseddd>: would you like me to include a seed corpus with the PR, sarang?
21:17:28 <sarang> Sure, why not
21:20:10 <derpy_bridge> <[keybase] unseddd>: ok
21:24:23 <sarang> Any findings of note?
21:29:06 <derpy_bridge> <[keybase] unseddd>: with the fuzzer? not yet, so yay! had an  unstable fuzzer that caused crashes using a 1MB file, but it was because my fuzzer was borked :/
21:30:06 <derpy_bridge> <[keybase] unseddd>: have let the current fuzzer run for ~10hrs, no crashes and over 100 paths explored
21:30:24 <selsta> btw current monero codebase could also benefit from fuzzing if this is something you want to look into after clsag :)
21:31:34 <derpy_bridge> <[keybase] unseddd>: selsta: definitely :) I <3 fuzzing, makes me feel all warm and ...
21:31:50 <derpy_bridge> <[keybase] unseddd>: _sees themself out_
21:31:53 <sarang> There's already fuzz testing in place for some code
21:32:42 <derpy_bridge> <[keybase] unseddd>: sarang: absolutely, I basically copied an existing fuzz harness for the CLSAG fuzzer
21:33:02 <derpy_bridge> <[keybase] unseddd>: I'm pretty impressed with Monero's test suite
21:33:25 <derpy_bridge> <[keybase] unseddd>: happy to help make it even more awesome
21:39:34 <sarang> I don't think there are any fuzz tests for MLSAG; that would be useful too
21:39:40 <sarang> (unless they do exist but I missed them)
21:55:08 <derpy_bridge> <[keybase] unseddd>: for sure, will look at MLSAG next
22:01:37 <moneromooo> There's a tx one, though I can't recall whether I made those pre-rct or not. In any case, it'd just be a matter of adding a rct tx in the dictionary.
22:02:10 <moneromooo> I have a feeling that most of the fuzzing is spent bashing one's CPU on "this hash is wrong" though, and so never going past early outs.
22:03:21 <derpy_bridge> <[keybase] unseddd>: moneromooo: that's why I asked about including a seed corpus, as they can greatly increase fuzzer effectiveness
22:04:00 <moneromooo> Feel free to add small interesting test cases which aren't easily reached by the existing ones.
22:04:32 <moneromooo> IIRC I added a typical and a minimal for each or so.
22:05:54 <derpy_bridge> <[keybase] unseddd>: will do. currently using a dumb random seed, will include seeds for: serialized valid CLSAG, serialized CLSAG with randomized {c,s,I,D}
23:12:06 <derpy_bridge> <[keybase] unseddd>: moneromooo: fuzzer is running much more efficiently now, thanks for the tip :)
23:13:06 <moneromooo> Cool, thanks :)
23:59:01 <derpy_bridge> <[keybase] unseddd>: no problem