Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for monero generate_key_derivation and subaddress/output … #3
Reviewers, please look at updated README.md first which explains the goals of this PR in particular.
On ryzen 3900x the speedup for
I have yet to do a speed comparison in wallet2 directly. I would not expect an exact ~140%-192% speedup because there are other factors limiting the scanning. The crypto operations are fairly dominant in the profile graphs though, so there will be decent gains. I will publish numbers at some point, unless it appears fairly quickly that this PR is going to be rejected.
@kenshi84 @hyc @stoffu @xiphon @moneromooo-monero there is somewhat advanced ASM in this PR. The ASM included here is adapted from the existing ASM in
The other options: (1) drop constant-time nature possibly leaking viewkey in some contexts or (2) 7 additional field inversions when generating the table for scalarmult. This table is needed when doing the ECDH for every tx (ed25519 typically does not have ECDH against arbitrary points, only
@moneromooo-monero @moneroexamples This was specifically designed to be usable in outside projects. I believe openmonero and monero-light-wallet-server can drop the dependency on internal
The other advantage to outside projects is all of this code should be easier to audit than the internal monero crypto library - the ref10 library should require zero changes and these amd64 variants only had position-independent changes to the ASM.
@moneroexamples I'm glad your initial reaction was positive. I primarily wanted to make you aware of this effort because there are significant performance advantages and ease-of-use if
Another thing I didn't mention - I can add support for
I was able to implement the two functions described in the
@b-g-goodell @SarangNoether @moneromooo-monero would be it easier to drop the amd64 stuff in this PR, and provide just the CMake + tweetnacl version for now? It would limit the review to just the library concept with a minimal C base implementation that can be reviewed by the MRL.
@vtnerd Thanks, this sounds awesome.
I'm trying to think of ways in which this leak could happen, it seems extremely low risk to me to drop constant-time ECDH blockchain scanning if it significantly improves performance
Please could you elaborate on what you mean here? What is it that is creating 7 additional inversions?
I'd assume that being able to do precomp is very useful for doing a scalarmult with e.g. H, right?
The monero daemon and viewkey are not necessarily on the same machine or owner. Monero now provides a mechanism for finding publicly available RPC ports for instance. The usage is clearly less common, but I think its preferable to "do the same thing" here and keep the behavior consistent with the existing Monero crypto code. This does have to be weighed against the complexity of having to review/maintain ASM code that is close but slightly different to the upstream project.
The arbitrary point scalarmult code (for use by the public-key in a transaction) generates a 3-bit "table" for performance purposes - it reduces the total point doublings needed. The size was chosen because (1) existing monero ref10 code creates a table of this size and (2)
The problem is the existing constant-time table selection ASM does not use projection (
Probably, but I haven't looked into that. We should be able to put a table in static-memory too, like with point-
It is also useful for doing scalarmult against a transaction public key when 2+ viewkeys have to be scanned against it. This occurs primarily in "light wallet" servers or any wallet tracking multiple primary accounts.