Open real-or-random opened 3 years ago
Unfortunately, the synthesis time of the current code seems to be exponential in the number of limbs (for WBW Montgomery) or at least cubic (for unsaturated Solinas), for unclear reasons. Our 12-limb example takes around 8 minutes, and just a couple more limbs brings us up to an hour. 3072-bit primes on 64-bit machines would involve 48 limbs, which is much more than the code can handle at this point. There are two issues, here:
Super-linear time in positional->associational->positional:
Super-linear time in chained-carries:
Super-linear time in WBW Montgomery multiplication:
N.B. This code runs with commit 4c54bbb0b89e5781d85f4a57b2f117f823a421a1 of our project. I expect it'll continue working for some time, but I'm leaving this commit hash here so it's easy to dig up a working version if we need to.
Some additional stats on WBW Montgomery multiplication (without arithmetic simplification):
Compute test3 0.
Set Printing Width 200. Compute test3 1.
This is almost perfectly quartic, as we can see on a log-log plot:
The number of lines of code in the generated C, by contrast, is almost perfectly quadratic:
Unfortunately, the synthesis time of the current code seems to be exponential in the number of limbs (for WBW Montgomery) or at least cubic (for unsaturated Solinas), for unclear reasons. Our 12-limb example takes around 8 minutes, and just a couple more limbs brings us up to an hour. 3072-bit primes on 64-bit machines would involve 48 limbs, which is much more than the code can handle at this point.
I see. Thanks for the quick and detailed response. I think then it's obviously then it's currently not interesting for us but I'll watch the issue of course. Unfortunately I don't have the resources to help.
As far as I understand, the focus of this project is ECC, even though other uses of finite field arithmetic are supported (Poly1305). Is it easily possible to support finite fields large enough that DLog is hard in them, e.g., primes of size ~ 3072 bits?
I know the cool kids use ECC nowadays but finite field DLog is not dead either. I'm specifically asking because Bitcoin is looking into MuHash [1] for incremental hashing for sets and finite field DLog is slightly more efficient for this use case in this context [2,3]. I wonder if fiat-crypto could be useful here. Specifically the linked PR implements finite field arithmetic for 2^3072 - 1103717 but since this a new feature, the choice of the prime is not set in stone.
[1] http://cseweb.ucsd.edu/~Mihir/papers/inchash.pdf [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html [3] https://github.com/bitcoin/bitcoin/pull/19055