Dan Wallach

@darkuncle@infosec.exchange @joebeone@techpolicy.social TRACTOR needs to solve three problems: correctness, performance, and idiomaticity. Correctness, in the face of AI translation, requires providing evidence of equivalence. To further complicate things, we neither want nor require bug-for-bug, vulnerability-for-vulnerability equivalence. That gives the translation process a significant amount of wiggle room. Fundamentally, we're talking about open research challenges. We're working to figure out how to do it!

@shriramk@mastodon.social When I was a grad student attending CCS '97 in Zürich, I ended up having an hour-long conversation with Ross Anderson in the otherwise empty hotel bar. Somehow I got over my fear and just approached him and introduced myself. Amazing, talking to a legend and having a real discussion about my career. More recently, on the paying it forward front, I was invited to a CRA event (representing DARPA, at the Watergate Hotel!) where I'd stay at a round table and ten fresh assistant professors would show up. We'd talk for 15 minutes, then DING, a fresh round and start over again. So, these kinds of things do occur, but they could definitely stand to happen more often. You just need to somehow break the ice, so prospective folks won't be afraid to even sign up.

@shriramk@mastodon.social I was invited to give a keynote at NDSS. I gave the first talk of the day. After that, I had a huddle around me, in the hallway, for the entire rest of the day. Lots of junior faculty asking for career advice. While exhausting, it's intensely rewarding to pay it forward. I like your calendar idea. See if you can get other folks to do the same, and make it a bigger effort, get the conference organizers to announce it, etc.

Update: Talk video is now online: https://youtu.be/3bAAVNKhsfY Webpage: https://www.ndss-symposium.org/ndss2026/keynote-by-prof-dan-wallach/

I've recently been playing around with vibe coding some basic tree-like data structures (treaps, red-black trees, AVL trees, and hash-array mapped tries) in Rust, and then twisting the arm of the LLM to do an optimization from Sarnak and Tarjan (1986) that lets you keep a version history without paying O(log n) path copying costs. This is the sort of thing that, in the old days, might have made for a useful undergraduate senior thesis that they'd crank on for a semester.

I'm at a point where I now have modest confidence in the correctness of my vibe code (e.g., it's got property-based tests that check the invariants, and also doesn't crash under load, despite lots of internal calls to Option::expect()), but I'm not confident enough to share it. It's not bad but not great.

At some point, I'll write up something useful about what I've learned about how to vibe code (in short, write vicious unit tests or you're doomed), but meanwhile I thought I'd skip straight to the data.

For comparison, I also included Rust's "im_rc" crate, which includes a human-written HAMT by
@bodil@social.treehouse.systems; I'm using the faster "Rc" version since that's how I vibe-coded all those others.

Punchline 1: @bodil@social.treehouse.systems wins. Their work is the "IM HashMap" in the graph. Higher is better. X-axis is problem size and Y-axis is throughput. The benchmark was 80% reads and 20% a mix of inserts, deletions, and updates. Every "version" is saved, creating (hopefully) real memory pressure.

Punchline 2:
The Sarnak-Tarjan optimization definitely helps for the various binary trees, but my attempt to do it for HAMT ended up costing a factor of two in perf. Yikes.

Graph below generated by Criterion.rs. Yes the colors are horrible. Measured on my M1 MacBook Air, because why not.

I gave a keynote talk last week at NDSS. I spent the front half talking about memory safety and how we can, once and for all, eliminate things like buffer overflows. In the back half, I talked about how DARPA works, saying all the things that I wish I'd known about DARPA when I was starting my own academic career. I also wore my favorite vintage aloha shirt.

A useful explainer about why static type systems, in general, and Rust, in particular, are super useful for debugging code.
https://blog.daniel-beskin.com/2025-12-22-the-compiler-is-your-best-friend-stop-lying-to-it

@mattblaze@federate.social @SteveBellovin@infosec.exchange @cstross@wandering.shop @Migueldeicaza@mastodon.social DARPA's TRACTOR (for which I'm the program manager) is focused on C to Rust, not C++. The Microsoft effort is unrelated to our effort. TRACTOR performer teams have been rolling for about six months now, and their first engagement with our test & evaluation team is going on now. As soon as it's ready, we'll push everything out for public release. There are many challenges with code translation: correctness, idiomaticity, performance. And there are many approaches. By the time we're done, we'll hopefully have good answers and good tools. (I could spend hours just on the topic of "C programmers do the darndest things", where it's sometimes unclear why something even compiles, much less what it's suppose to mean.)

This is great: https://blog.trailofbits.com/2025/11/25/constant-time-support-lands-in-llvm-protecting-cryptographic-code-at-the-compiler-level/

LLVM 22 (and presumably all the subsequent versions) now have a constant time select intrinsic to enable cryptography algorithms to tell the compiler exactly what they need (i.e., evaluate both sides of a conditional expression then select the one you want), replacing gross bit hacking expressions that newer optimizers would unravel.