Recently, Milad Nasr and Nicholas Carlini used an AI model to improve an earlier attack on seven-round AES-128 . And Satoru Kanno (@satokan3) wrote a great explanation of the result in Japanese . Here’s a walkthrough based on his blog post and my understanding of the results, in English. TLDR: Don’t panic. It’s an incremental improvement to an impractical reduced-round attack. Full AES-128 remains…
There’s an old problem with AES when implemented in software: it’s either slow or insecure. AES has a state of sixteen bytes, and a round has four steps: SubBytes replaces every byte using the AES S-Box. ShiftRows moves bytes to different columns. MixColumns combines the four bytes in each column. AddRoundKey XORs another sixteen-byte value. And SubBytes is the annoying part, because it applies a…
In 2023, I wrote that the best WebAssembly runtime may be no runtime at all . To summarize: if you already have a WebAssembly module, translating it to C and compiling that C with a normal native compiler can be surprisingly hard to beat. I expected that argument to get weaker over time, because WebAssembly runtimes keep improving. Their compilers have better register allocators, better lowering,…
The new lazy comment’s “AI-generated”. On Hacker News, every thread about a programming language that isn’t Rust eventually gets a Rust comment. It doesn’t matter if the topic’s C, Zig, Go, PHP, Elixir, or a database. Somebody will find a way to turn the discussion into Rust. We now have the same reflex for writing. Someone publishes a blog post. Maybe something a shower thought. Maybe just a…
I wanted to know if WebAssembly runtimes are getting faster. This is a follow-up to the earlier libsodium WebAssembly benchmarks from 2019 , 2021 and 2023 . Not “does the newest version beat native code in one microbenchmark?”, and not “which runtime has the prettiest benchmark chart?”, but something more boring and more useful: If I take the same C crypto code, compile it to WebAssembly, and run…