anomalroil

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 ^^''

Depends if you want the RTX 5090 before next year or not, just like the collision :P

Too bad you didn't try it with much higher degrees.

Speaking of Monte Carlo, here's a paper about how using bad randomness can lead to wrong simulation: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2992609/ (or should I call them _biased_ ones?)

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.)

Or rather, observing a network meant to produce randomness in a distributed way.

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.

That would be a pretty cool way of achieving timelock, sure, but might not be super practical.

Timelock using trusted third parties was first proposed in 1993 by Tim May, the founder of the crypto-anarchist movement, yeah.

Almost, the randomness is generated using a BLS signature that also makes it verifiable. And that signature is the decryption key.

Except for the math part when the slides were frozen, I guess :P

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.

Ahahah, definitively. Where's the challenge otherwise? The PoC was ready since almost 8 months sitting in a branch of drand/kyber, and the Go tlock library since a month or so and it would have been enough if it weren't for the DEF CON presentation that made a web-demo more appealing for people to try it out :P

This is based on a permissioned threshold network, so as long as there are never a threshold number of nodes that are malicious and as long as there is a threshold number of nodes that continue to operate, the network's liveness and security is guaranteed. Using Bitcoin as a cryptographic reference clock has been proposed in the past, but the good way of doing it is relying also on SNARKs and isn't really that practical from what I can tell: https://link.springer.com/content/pdf/10.1007/s10623-018-046...

Yeah, it's not exactly how it works, but close. The League's node ran together a distributed key generation that created a secret key for the whole League so that it's sufficient to have only a threshold number of nodes to recreate that secret key. But since it's using threshold cryptography, it doesn't even ever need to recreate the secret, it can simply aggregate "partial signatures" into valid signatures for the group's public key. The timelock scheme itself relies on so-called "identity-based encryption", so that you can encrypt a plaintext towards the signature of a specific message. And you know in advance that the League is going to sign round number X at time Y, so you can encrypt towards the signature of the round number X, and once it's produced, that signature allows to decrypt the ciphertext. Pairing-based cryptography is kinda magic on that front :)

Yes and no: it's not a blockchain. It's relying on the fact that the drand network is producing distributed, verifiable randomness using a threshold scheme with distributed key generation. So the secret key of the group is never in memory on any device and the only way to obtain a valid signature for a message is by having a threshold number of "partial signatures" being produced by the drand nodes in the network. Currently it relies on the League of Entropy network, run by Cloudflare, Protocol Labs, Ethereum Foundation, Kudelski Security and other organizations, including multiple universities. So the security is relying on the fact that the network's goal is to produce public randomness, and that parties have no reason to collude. For instance the League of Entropy is used for leader election and randomness by Filecoin, so it's already "securing" a lot of things, adding timelocked data on top seems like a nice way to use the network. And yeah, if there are ever a threshold of nodes colluding to produce a signature "too early", that's sadly not detectable.

Encrypting something that cannot be decrypted until a given future date is now possible :D This was presented on Friday at DEF CON, and there's also a web demo to try it out using the second compatible TS library: https://timevault.drand.love/

Everybody keeps telling me about asdf, but I haven't yet come around to using it. I like to have manual control over my packages, but I guess I should really give it a try one day.

Beware, here comes the machine learning on top of encrypted data using functional encryption: https://github.com/fentec-project/neural-network-on-encrypte...

I love how ECDSA is used more and more to do authentication, but ECDSA is arguably not the best if you're going to implement new stuff... I wonder when Ed25519 is finally going to be adopted by hardware tokens. I can see it's in the COSE algorithm list, so in theory it's should be accepted by the standard.

I think it was found thanks to Wycheproof, which is quite cool.

Remembered me of the fun "Angecryption", where you can decrypt the ciphertext with AES or decrypt it with DES and get different plaintexts depending on the scheme: https://github.com/indrora/corkami/blob/master/src/angecrypt...