I like the idea of making the index deterministic

sweet. i'm thinking that'll help a little with the view-only wallet balances

what about removing tx creator control of indexes altogether? would deterministic indexing achieve that?

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

derbleak i'd be interested if you could figure out how to let the outside world check that without disclosing the real indices

zkp to the rescue :)

mb even just pedersen commitments

idk

btw i was looking at your 454.pdf earlier. i don't understand the math, but what an awesome achievement

right 0.0 still reading through it

so excite

is that borat or doggolingo

lol

upick

i'll err on the side of doge, since borat would say "i very excite"

knaccc: you can't check that though, right?

Whereas the deterministic scalar method _can_ be checked

(but a wallet not doing it will be missed)

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

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

No, I mean that the deterministic index is unreliable

in a way that deterministic _scalars_ are not

i think perhaps i don't understand what you mean by deterministic scalars

i thought you were referring to the change_tag stuff

i.e. that you can verify the commitments match your alternatively-encrypted ecdhinfo amount

How would you define the order for ring membership? Afaik right now the order is just member age

interesting, i'd assumed they were currently shuffled randomly

i guess actually they were never shuffled randomly right? due to the way indices are encoded

yeah that's a good question.

The order within a ring is blockchain order. Delta encoded. There's no point in shuffling them really, is there ?

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

moneromooo right yes the delta encoding

That's... a point for shuffling ?

i'm agreeing that the delta encoding prevents shuffling

and therefore you'd have to choose the decoys such that the intended real indices work out

Well, doesn't really. It just is the smallest way to encode it (in the general case).

yeah i'm assuming we wouldn't want to mess with the compactness of the delta scheme

or have to invent negative varints

They can use the same system.

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.

I think one of Matthew Green's students actually made an actual test of this.

interesting, i am in favor of deterministic decoy selection

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?

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.

oh yes, that's a much better idea

I'm unsure whether that offset would leak anything.

The offset thing will likely skew the distribution, so *some* amount of brute forcing will likely be wanted anyway.

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

imho, removing the offset entirely would be ideal (via deterministic decoys or w/e)

what is w/e?

whatever

whatever means work + meet design reqs

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

EC ops are more cryptographically sound

some cryptographic method of generating decoys is preferable, imho

hashes count as a cryptographic method, and those are very lightweight compared to EC ops

where is the bruteforcing involved with hashes in this context?

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

this is just about decoy selection, EC ops should never need to come into it

why not make the index a hash(pubkey | input | w/e)?

i'm sure constructs like that will go into the more complex task of determining a good scatter of decoys

then receiver search for index matching hash(signing/view pubkey | input | ... )

ironically larger ringsizes might reduce the amount of bruteforcing required

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

great point

The method suggested by Green's student doesn't play nicely with the more complex distribution we use

But it's a hashed shuffle with an offset

You need a transform from uniform selection to the desired distribution

potentially relevant: fastd.readthedocs.io/en/v18/crypto/fhmqvc.html

mentions use of TLV for auth tags

similar to one of the points discussed in monero/6456

(implicit PFS is a big win)

Hello all

hi

good monrign

Anyone heard from Surae ?

I chatted with him a couple of days ago, briefly

I'll take that as a positive sign.

New PR to fix up in-memory key encryption: monero-project/monero #6474

Review requested

So I'm considering the implications of adding message authentication to encrypted files within the ecosystem, after a suggestion was presented about this

Any particular downsides to this?

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

If that happens, the authentication is useless

examples of encrypted files that would need to transition?

e.g. ringdb information

and e.g. github.com/monero-project/monero/bl…r/src/wallet/message_store.cpp#L692

Since key derivation is different between plain-old ChaCha20 and ChaCha20-Poly1305, the risk may be low

<[keybase] unseddd>: an attacker tricking a user to use an old client to perform decryption sans MAC is no worse than the current situation

although a user who believes MAC would protect them, might be mistaken

correct

<[keybase] unseddd>: a user being tricked to use an old client to decrypt wallet files has more problems than MACs

It's not about an old client necessarily. It's that old files legitimately have no MAC

and need to be decrypted successfully in order to transition to a MAC construction

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

and therefore may not be a problem

<[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)

<[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

<[keybase] unseddd>: obviously not as workable to start from scratch with everything, but maybe for the ultra-paranoid

<[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

Yes. I mean that I don't consider there to be a risk of a downgrade attack

That is, CCA for an attacker who takes a post-poly wallet and tries to downgrade by stripping out the tag

<[keybase] unseddd>: tangent: have a stable fuzz test running! will PR after letting it run a bit longer

<[keybase] unseddd>: ^ for CLSAG

neat

<[keybase] unseddd>: would you like me to include a seed corpus with the PR, sarang?

Sure, why not

<[keybase] unseddd>: ok

Any findings of note?

<[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 :/

<[keybase] unseddd>: have let the current fuzzer run for ~10hrs, no crashes and over 100 paths explored

btw current monero codebase could also benefit from fuzzing if this is something you want to look into after clsag :)

<[keybase] unseddd>: selsta: definitely :) I <3 fuzzing, makes me feel all warm and ...

<[keybase] unseddd>: _sees themself out_

There's already fuzz testing in place for some code

<[keybase] unseddd>: sarang: absolutely, I basically copied an existing fuzz harness for the CLSAG fuzzer

<[keybase] unseddd>: I'm pretty impressed with Monero's test suite

<[keybase] unseddd>: happy to help make it even more awesome

I don't think there are any fuzz tests for MLSAG; that would be useful too

(unless they do exist but I missed them)

<[keybase] unseddd>: for sure, will look at MLSAG next

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.

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.

<[keybase] unseddd>: moneromooo: that's why I asked about including a seed corpus, as they can greatly increase fuzzer effectiveness

Feel free to add small interesting test cases which aren't easily reached by the existing ones.

IIRC I added a typical and a minimal for each or so.

<[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}

<[keybase] unseddd>: moneromooo: fuzzer is running much more efficiently now, thanks for the tip :)

Cool, thanks :)

<[keybase] unseddd>: no problem