You can verify in limited memory by repeatedly verifying modulo a few small integers. If that works, then by Chinese remainder theorem the main result also holds.
Besides the data being signed as already mentioned, the protocol is interactive and custom to passport documents. So you can’t just put it on any programmable NFC tag. I also doubt you can buy programmable ones implementing the passport protocols. But maybe you can find general purpose programmable ones you can implement the protocol on.
There are also optional subprotocols that allow the chip to be authenticated (i.e. proof it knows a private key). These prevent copying valid signed data to a different chip.
It’s well known GPUs are good at cryptography. Starting with hash functions (e.g. crypto mining) but also zero knowledge proofs and multi party computation.
Did you verify this through disassembly? These loops can still be replaced by a closed form expression and I wouldn’t be surprised if LLVM figured this out.
For me it means I can fork the repo and start hacking on the code immediately, and it will have reasonable quality.
With C++/Python and even Node I often find myself wasting half a day just getting it to build.
Correct. I was too short in my comment. It's explained in the article: without loss of generality you can call one of the two points the 'north pole' and then the other one will be distributed close to the equator.
The distance between two uniform random points on an n-sphere clusters around the equator. The article shows a histogram of the distribution in fig. 11. While it looks Gaussian, it is more closely related to the Beta distribution. I derived it in my notes, as (surprisingly) I could not find it easily in literature:
Exactly, and this is in my experience what most Rust code ends up looking like.
It compromises a bit on generality and (potential) performance to achieve better readability and succinctness. Often a worthwhile trade-off, but not something the standard library can always do.
Why should we weigh by the number of different digits? I.e. is there an argument why the cost of a single digit is linearly proportional to the number of values it can hold?
To me this seems like the weak point in the argument.