00:44:00 Added a comment elaborating the idea a bit: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#gistcomment-4022720 13:14:44 I am cleaning up my code which generates and scans various address/output formats. I want to select variable names that are readable and usable as well as consistent across algorithms. 13:14:49 What has anyone here seen in code that they liked or disliked (and why) 18:38:20 another idea: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#gistcomment-4023680 21:02:05 hmm I think it would work, feels a bit unwieldy (inelegant? limited utility?) 21:07:01 We should compare cost vs benefit. Encrypting (i,j) with k_a^i is more useful, but still requires some brute forcing and has a much higher cost (8 bytes per address, 8 bytes per blockchain output) 21:09:45 It could probably be reduced to 5 bytes (encrypt just j + MAC) 21:42:51 How many bytes is the encrypted amount in a transaction? 21:43:41 With a 2-byte MAC I think the amortized cost of brute forcing is just ciphering the encrypted indices of view tag matches with each account key (only 1/2^24 outputs unowned by an account would leak through to that account's final nominal spend key check). Most users will have a very small number of accounts, and the API can even require that the accounts to search be user-defined (a reasonable constraint imo). It might 21:43:41 be helpful to know ballpark costs for ciphering... 21:43:41 The goal here is that a user can reliably identify all of an account's outputs, even if those outputs are received to an unknown address index `j`. With index-encrypting, the user-cost is ciphering all view tag matches (with very minor expense to test nominal spend keys when the cipher MAC passes). With a `j`-database, the user-cost is either storing a huge table or connecting to a third-party (which is very hard to 21:43:41 implement in constant time with no/minimal privacy losses). It's possible that additional requests to a third-party to consult a `j`-table would be _slower_ than ciphering indices (especially for small updates). 21:44:42 wernervasquez[m]: 8 bytes; personally, 4-6 bytes per output feels insignificant (assuming the benefit to users is tangible) 21:45:48 I will move my comments over to the gist for better retention 21:49:00 Hi All, I have been contacting some 21:49:00 People individually to ask if they want to participate in MoneroTopia.com But I just want to put this general message out their to all Monero devs/researchers/contributors to please reach out to me if you would like to be a speaker or know someone you believe I should reach out to. If so, please message me. 21:49:00 -D.Tuman 22:09:34 tevador: With Blowfish I think the MAC can be implicit. Since Blowfish blocks are 8-byte, but we only need 4 bytes, we can check if the upper 4 bytes of a decrypted index match the expected padding. `enc_data = enc[k](j | 0-padding); dec_data = dec[k](enc_data); if (dec_data[4..7] == 0) then pass`. 22:10:01 err no not implicit; I mean the MAC doesn't require a separate algorithm 22:10:29 Yes, that's one option, but a 4 byte MAC seems like overkill 22:11:27 1-byte MAC would be more than enough (only 1 in 65K outputs would need to calculate the spend key) 22:11:48 Now that I think about it, I think the encrypted index MUST equal the block-size of a block cipher. 22:12:04 Removing bits would invalidate the block 22:12:19 Yes, with a 1-byte MAC, we'd need a 32-bit block cipher 22:12:53 not many of those exist 22:15:02 anyways, we should summarize the pros and cons of each option (default, j-database, encrypted index) for the meeting to decide 22:26:05 I am going to try and benchmark blowfish a little 22:31:33 I think it's quite fast except of the initial key expansion 22:36:41 yeah, but all the benchmarks are for large data packets 22:43:11 I estimate that calculating the discrete log of K_j using the baby-step giant-step algo should take around 20 ms per account, so it's not impossibly slow (but still *much* slower than decryption)