So you want to serialize some DER?

https://alexgaynor.net/2025/jun/20/serialize-some-der/

76 16 1 year ago

PeeMcGee• 1 year ago

The post title is misleading and the content reads more like a guerilla advertisement for claude. TL;DR: author works for Anthropic, and used claude to implement an optimization for LLVM.

quentinp• 1 year ago

He’s also well respected in the Python community for maintaining the cryptography package, partially written in Rust. This is just a random blog post, not an ad.

lmm• 1 year ago

Maybe. But the fact they work for Anthropic is very relevant and changes my impression of the post quite a lot.

brabel• 1 year ago

The author has added a note in the beginning of the post now making it clear that he works for Anthropic, which may explain the fixation on Claude Code!

benmmurphy• 1 year ago

having two very different code paths for measuring the length of the DER buffer and writing the DER sounds very scary. i guess its fine with Rust but the idea would give me the heebee-jeebies for any other language unless they are using a safe buffer implementation. i would find it hard to trust that there is no buffer overflow based on divergent behaviour between the two functions.

tptacek• 1 year ago

This piece starts out super-duper inside baseball (optimizing DER encoding for, in the main, X.509 certificate handling) in Rust code that is increasingly leveraged by Python's cryptography stack. But it ends up somewhere crazy: with an LLM agent apparently one-shotting an LLVM optimization, then semiformally verifying the change, which is ultimately merged by the LLVM team.

ggm• 1 year ago

So many encoding rules. DER, PER. It's an xkcd cartoon but inside one asn.1 standard!

dathinab• 1 year ago

it's as much one standard as OIDC is ;)

(as in it isn't one standard but a group of standards, like asn.1 without any encoding is split in ~4 standards by itself. Through to be fair all or CER, BER and DER are in the same standard. But PER is another standard, so is XER, OER, JER, GSER, RXER each and others.)

jnwatson• 1 year ago

The standard is 41 years old, so there has been plenty of time for extensions.

Practically, the useful encodings are DER, which is canonical and used for crypto, and XER, which is human-readable.

It is a neat spec, chock-full of great ideas. Unfortunately, given its age, there have been many bad implementations of it.

zzo38computer• 1 year ago

There’s only one encoding I choose to acknowledge, which is DER (the Distinguished Encoding Representation, it’s got a monocle and tophat).

I also prefer to use DER, because it is better than BER and CER. DER is actually a subset of BER but BER has some messiness which is avoided by DER; because there are not as any ways to encode data by DER this makes it simpler to handle.

DER is also the format used by X.509 certificates, so this is fortunate; however, I use DER for other stuff too (since I think it is generally better than XML, JSON, CSV, etc).

I wrote a library in C to serialize and deserialize DER.

NoahZuniga• 1 year ago

DER encoding is in fact unique.

simonw• 1 year ago

The most interesting part of this post is the bit about half way down, where Alex uses Claude to help identify a missing compiler optimization in LLVM... and then uses Claude Code to implement that optimization and gets a PR accepted to LLVM itself! https://github.com/llvm/llvm-project/pull/142869

CJefferson• 1 year ago

I feel this is going to be the thing which really boosts automated theory proving.

Up until now it's always been a hard sell, people say "Well, I can prove it myself, and that's less work than getting the computer to prove it", and they weren't completely wrong.

However, now we have LLMs which can do lots of interesting work, but really can't be trusted for anything important (like an LLVM optimisation pass, for example). If those LLMs can convince a theorem prover the LLVM optimisation pass is correct, then suddenly their output is much more useful.

tialaramex• 1 year ago

One concern here is that proofs don't necessarily prove what we intuitively think they do. So we need to be very careful to understand what we actually proved.

The TLS 1.3 "Selfie attack" is an example of a gap between what we did prove and what we intuitively understood.

The formal proof for TLS 1.3 says Alice talking to Bob gets all the defined benefits of this protocol, and one option is they have a Pre-shared Key (PSK) for that conversation. They both know the same key, in that sense it's symmetric.

But the human intuition is that we're talking about an Alice+Bob key, whereas the proof says this is an Alice->Bob conversation key. If we re-use the same PSK for Bob->Alice conversations too we get the Selfie Attack, the formal proof never said we can expect that to work, it was just our intuition which confused us.

GoblinSlayer• 1 year ago

The article says the proof only considered session resumption PSK, and overlooked out of band PSK, which was left for future work. Maybe if they could have a list of features, but TLS is too complex for that.

Also PSK involves sending a PSK identity, which is supposed to be used to find the PSK, in particular it can be a user name, so the server can check the user name is correct.

So you want to serialize some DER?

Related Stories