bigfoot-sim
toy-rsa
| bigfoot-sim | toy-rsa | |
|---|---|---|
| 1 | 2 | |
| 0 | 2 | |
| - | - | |
| 5.3 | - | |
| 6 months ago | over 2 years ago | |
| Rust | C | |
| - | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
bigfoot-sim
-
How hard can generating 1024-bit primes be?
Nice article! I've also rolled some of my own bigint code recently (for earlier versions of [0]), and I can recall how frustrating it was to translate high-level descriptions in math papers into actual operations.
I do have a small quibble, though:
> At this point, the BigInt is using base-(2^64-1) or base-18446744073709551615 () and it only needs 16 "digits" to represent a number that uses 309 digits in base-10!
If you use the full range of a u64, then your number will be in base 2^64, with each word ranging from 0 to 2^64-1, in the same way that base-10 digits range from 0 to 9.
[0] https://github.com/LegionMammal978/bigfoot-sim
toy-rsa
-
How hard can generating 1024-bit primes be?
That's actually just a bug: the x86 asm constraints were needlessly forcing the compiler to use rdx as the input register for the multiply instruction.
With that fixed, it's the same: https://godbolt.org/z/M571P371K
But after staring at this for a little while, I realized simply reversing the order of the fields in the dword struct will make the result from the multiply instruction already match the way 128-bit structs are returned in registers under the x86_64 calling convention! This is quite a bit better: https://godbolt.org/z/MbfG63vej
Also worth noting the asm makes nicer code on arm64: https://godbolt.org/z/7eas6s9vK
https://github.com/jcalvinowens/toy-rsa/commit/59ef9ea905dbd...