it's also a fairly forced acronym in the crypto case 😁

This has felt like an impenetrable super hard-to-understand paper since the start of grad school, and it feels good to more or less understand Lasso/Twist and Shout. Minor warning that TaSSLE uses weird notation in a few places.

Unlocking the lookup singularity with Lasso This paper introduces Lasso, a new family of lookup arguments, which allow an untrusted prover to commit to a vector $a \in \mathbb{F}^m$ and prove that all entries of a reside in some predetermined t...

I recently spent some time reading "Unlocking the lookup singularity with Lasso" (eprint.iacr.org/2023/1216) and the sequel papers. I think TaSSLE (eprint.iacr.org/2024/1075) is the best companion/exposition work for understanding Lasso of the ones out there.

"keyses"??? did gollum name the variables in this paper?

I do think this weird ethics appendix does raise some good points about how the current ethics guidelines for security conferences just aren't that well suited to crypto papers

new blog post! The USENIX Security '26 Call for Papers has examples of the required Ethics Appendix which they think are well written. If you read the example ethics appendix for cryptography, it is actually somewhat strange: www.sasha.place/blog/2026/04....

i just got a cold email offering 70$ an hour for a "tutor" role where I would mentor a high school student on a research project to submit to high school science fairs. crazy stuff

They have now :D

have the notifications been sent yet?

these reviewers write (Very) Knowledgeable as an estimate of their knowledge levels. how?

more complaining about paper reviews: I have now twice gotten the paper review comment "can you do a tight, concrete security reduction?" for protocols using zk-SNARKs as a subcomponent. No paper in the applied SNARK literature does this! it's messy!

(taken from the Twist and Shout paper)

performative zk-SNARKs 🙄 wearing tote bags and stuff

New preprint is up! We put it up so we can submit to poster sessions, I will write more about it when it gets accepted.

credit where credit is due: this AI generated code is the only research-grade cryptography code I have ever seen that tried to properly do domain separation.

typod zero-knowledge as "aero-knowledge". we're going aero knowledge baby 😎

this mistake is really scary because i can definitely see somebody looking at this and thinking "yeah looks fine"

when hashing a multiset with m elements in a field of size k, this achieves a security level of O(k^(1/(1 + log m)))!!! (see www.enseignement.polytechnique.fr/informatique...)

adventures in vibe coding cryptography: I was asked to review some AI generated cryptography code. It implemented a multiset hash function which computed the hash of a multiset by hashing each element individually with Poseidon, and then adding them together as field elements.

another complaint about zkVMs that isn't frequently brought up: for reasonably large programs, compiling/running your code takes a few minutes, which is super disruptive to staying focused.

a unique winter sight in College Park: a common sledding location is the hill next to the IONQ office :)

The other hair tearing moment is that we wanted our RISC-Zero code to interoperate with some optimized Nova circuits. Poseidon is comically slow on RISC-Zero because of the inefficiency of compiling large field operations to a 32 bit ISA (like 500k-1 million CPU cycles per hash).

I was looking over the former student's code and you could make it 3x faster by patching in the SHA-256 precompile. Like a 1 line change which is kind of buried in the documentation makes this fairly natural code 3x faster.

I have to work on a project for grad school which uses the RISC-Zero zkVM. Reiterating a hot take I have had previously: zkVMs are not actually that developer friendly as soon as you need to try to optimize your code in any way!

There was a small proof I was stuck on, so I asked a few different AI assistants to help me prove it. They were all wrong, but ChatGPT did give a correct outline of a proof, where it was correct after working out the details.

and this is why they thought our application of Fiat Shamir is insecure.

i now realize that the reviewer's real issue is that they don't understand how a proof system like Spartan supports random in-circuit challenges (you generate randomness that depends on the private witness w by hashing the value of the polynomial commitment to the witness)

they also confused fixed point and floating point arithmetic and then used that confusion as a point against us.

and then says our protocol is potentially insecure because of this. Is this not common knowledge??? If you incorrectly implement F-S, the protocol will be insecure.

i got rejection #4 of grad school today! I got a new insane reviewer highlight: Our paper says "this protocol can be made noninteractive via the Fiat-Shamir transform" in a few places, and the reviewer comments "if you don't pass everything into the F-S hash function, this would be insecure".