Added a comment elaborating the idea a bit: gist.github.com/tevador/50160d160d2…52ae02eb3d17024#gistcomment-4022720

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.

What has anyone here seen in code that they liked or disliked (and why)

another idea: gist.github.com/tevador/50160d160d2…52ae02eb3d17024#gistcomment-4023680

hmm I think it would work, feels a bit unwieldy (inelegant? limited utility?)

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)

It could probably be reduced to 5 bytes (encrypt just j + MAC)

How many bytes is the encrypted amount in a transaction?

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

be helpful to know ballpark costs for ciphering...

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

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

wernervasquez[m]: 8 bytes; personally, 4-6 bytes per output feels insignificant (assuming the benefit to users is tangible)

I will move my comments over to the gist for better retention

Hi All, I have been contacting some

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.

-D.Tuman

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`.

err no not implicit; I mean the MAC doesn't require a separate algorithm

Yes, that's one option, but a 4 byte MAC seems like overkill

1-byte MAC would be more than enough (only 1 in 65K outputs would need to calculate the spend key)

Now that I think about it, I think the encrypted index MUST equal the block-size of a block cipher.

Removing bits would invalidate the block

Yes, with a 1-byte MAC, we'd need a 32-bit block cipher

not many of those exist

anyways, we should summarize the pros and cons of each option (default, j-database, encrypted index) for the meeting to decide

I am going to try and benchmark blowfish a little

I think it's quite fast except of the initial key expansion

yeah, but all the benchmarks are for large data packets

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)