These precompiles were long overdue, IMO. Good think to see them finally being available on Mainnet, but I wonder if we'll see the migration away from the much weaker BN254 pairing-friendly curve to the stronger BLS12-381 one prior to post-quantum alternatives being available as precompiles ^^''
As you said: Java's Random is not meant for serious cryptographic usage, it's meant to be super fast.
You have SecureRandom instead for cryptographic usage, and it's noticeably slower.
Interestingly, using fast, but bad random generators such as Java's Random was shown to be an issue multiple times in the past already for things such as Monte Carlo, and so on, not just for things related to security.
It does but it does not! java.util.Random is not a CSPRNG at all and is terrible, so even tho the nextInt() method is using rejection sampling, it's still producing biased values and also completely fails to be "unpredictable" because java.util.Random is weak and predictable.
Lemire's technique is really nice, in general a good thing to learn about, since it's a bit mind bending how it's playing with intervals. Sadly last time I benchmarked it in code on x86-64 for cryptographic purposes, it wasn't faster than rejection sampling, or just using a large value and a modulo reduction: in all cases what is actually taking a lot of time is the call to get good quality randomness out of a CSPRNG, the rest being negligible in comparison.
Notice that nowadays, unlike 2 years ago, people usually recommend to use the last technique I presented there in the last paragraph before the Conclusion. Which is to generate a random value that is big enough, so that n-log(p) > 128 so that the bias will be too small to be exploitable in practice. It's simpler and unlike rejection sampling ensures your code cannot fall into an infinite loop in case your PRNG is broken. (I'd argue you might want your code to fail in that case anyway, but YMMV.)
It could, and that's why a solid threshold network should have nodes in different locations, jurisdictions, cloud providers, etc. and have a threshold that's high enough to avoid that risk.
Also, be careful of a "last player attack" when XORing randomness: if your last source could spy on the state of your buffer, or on all other randomness sources, it can trivially craft a string that would XOR to a specific value once XORed with the other sources.
Yeah, I guess that's a fair way of describing threshold cryptography and a threshold network. There was actually already once a proposal of creating a "timelapse encryption service", by Rabin in 2006 (https://dash.harvard.edu/handle/1/26506434) they said they were planning on implementing and deploying such a service, but it never made it AFAIK.
The main difference here is that it's relying on an existing service providing also something else, namely public randomness, and that this service has been running for 2 years and never had any disruption so far.
In any case another assumption is that there are no quantum computers able to break your ciphertext since every primitive used here is broken by quantum computers. So it would be ill-advised to use it to encrypt something that cannot be decrypted until 10, 20 or 50 years, since it might well be broken by then if even if the network survived.
But for near-future things, it works well.
Well, Timelock Encryption is "encrypting somewhat towards the future", and as explained in the talk, in 1996 "Timelock puzzles" were proposed by Rivest, Shamir and Wagner as a "proof of work" based system to achieve it. Sadly that's very sensitive to hardware evolution, and when Rivest tried to create a puzzle meant to last 35 years in 99, it ended up being broken in 2019 after only 20 years. It was even doubly broken: once by a guy running it on his CPU for 3.5 years only, and once in only 2 months by a FPGA/ASIC implementation done by the Cryptophage collab between Ethereum Foundation, Supranational and Protocol Labs... Other names that are also about achieving timelock encryption include "timelapse encryption" and "timed release encryption". Some people do a distinction because for instance the timelock puzzle are mostly about achieving a lower bound on the time it requires to solve them but aren't mapping well to a precise time. VDFs are promising tools to achieve timelock or timed released encryption, for sure.
Yeah, that's not exactly how it works. The drand nodes are publishing random beacons that are signed, that's the only thing the networks does. Publishing public verifiable randomness. But pairing-based cryptography allows us to do identity-based encryption and that's like magic, but basically we can rely on a message as a public key, and on a signature as a secret key, and that's how tlock works.
Onboarding new members on a drand network is fairly easy: there only needs to be a threshold of nodes doing a resharing ceremony and all nodes get new shares and new nodes can be onboarded like that. It's not handled by tlock or timevault, it's on the League of Entropy side and is how drand works. More details are in https://drand.love/docs/cryptography/
It works by relying on identity-based encryption to encrypt plaintext that cannot be decrypted until the signature of a specific message is revealed. The League of Entropy is signing its beacons every 30 seconds and so acts as a reference clock to provide the signatures on time.