09:56:29 <kayabanerve[m]> UkoeHB: Why was Twofish chosen over Chacha re: JAMTIS? I only see the reasons for not Blake2b, not not Chacha.
10:10:03 <sech1> What's wrong with Blake2b?
10:18:59 <kayabanerve[m]> sech1: Nothing, yet Twofish was chosen over it for perf (a choice I wouldn't agree with due to the complexity of incorporating Twofish as a primitive).
10:19:29 <kayabanerve[m]> Chacha should be competitive on perf/faster, more widely usable, have more libs actively maintained, and shares some cryptanalysis with Blake.
10:20:06 <sech1> Blake2b is already in Monero codebase though
10:22:37 <kayabanerve[m]> I'd prefer Blake2b to Twofish. I'd prefer Chacha to Twofish, which I think is also in codebase yet I'd have to check. If Blake2b is out for perf, we should evaluate the potentially faster, in family, more popular Chacha.
10:23:52 <moneromooo> chacha20 is in the codebase (it's used to encrypt the wallet file).
11:13:41 <someoneelse49549> <kayabanerve[m]> "Chacha should be competitive..." <- any thoughts about blake3 ? or Is it just not suitable ?
11:18:04 <kayabanerve[m]> Blake3 may make sense for large data sets. This isn't a large data set
12:15:05 <UkoeHB> kayabanerve[m]: chacha and blake2b are not block ciphers
12:15:32 <kayabanerve[m]> Yes, but why do you need a block cipher?
12:15:34 <UkoeHB> chacha requires an iv
12:15:44 <kayabanerve[m]> And despite Blake2b not being a block cipher, it was still evaluated.
12:15:47 <kayabanerve[m]> Only if they key is reused.
12:15:47 <UkoeHB> with a block cipher you can do a single block with no iv
12:16:12 <UkoeHB> the key has to be reused for ciphering the index
12:16:20 <UkoeHB> ciphering the indices of all addresses*
12:17:03 <kayabanerve[m]> ... and then are we sure calculating unique IVs + Chacha isn't faster?
12:17:03 <kayabanerve[m]> If so, ack, just running this to completion.
12:17:14 <UkoeHB> how do you get a unique iv?
12:17:30 <kayabanerve[m]> Uhhhhh I think you can just use a counter.
12:17:44 <UkoeHB> how do you recover the unique iv during balance recovery?
12:17:56 <kayabanerve[m]> I won't sign off on that but known IV isn't a break, if you know two distinct IVs, AFAIK. So as long as the IV uses are ordered, it should be near-free.
12:18:08 <kayabanerve[m]> * a break, even if you
12:18:42 <UkoeHB> in balance recovery all you have is an address tag with no other information, how do you get the proper iv?
12:19:58 <kayabanerve[m]> *I'm not sure the IV uses are ordered. I'm saying I don't believe we need additional hashes to calculate IVs so the performance is possibly still viable.
12:20:00 <kayabanerve[m]> If we don't have the ability to add in any other context, and keys aren't unique, we don't have a mechanism.
12:20:11 <kayabanerve[m]> So then sure, an IV-less system makes sense if you absolutely can't change that API.
12:20:53 <kayabanerve[m]> I'd have to read the exact flow. I just find it surprising if we are so rigid. I'm unsure why we'd have non-unique keys in the first place since shared keys are now binding to linking tags (or at least, some shared keys are).
12:21:08 <UkoeHB> section 8.5.2 step 5 https://raw.githubusercontent.com/UkoeHB/Seraphis/master/implementing_seraphis/Impl-Seraphis-0-0-2.pdf
12:22:16 <UkoeHB> Address tags are attached to addresses, encrypted address tags are attached to enotes. Encrypted address tags use blake2b just like encoded amounts.
12:23:51 <kayabanerve[m]> I see the issue. Thanks for linking that. I'll drop my commentary.
12:24:08 <UkoeHB> 👍
12:24:39 <kayabanerve[m]> So we do need a block cipher, which is why Twofish is the best candidate. Got it.
12:24:48 <UkoeHB> yep