briansmith

Are they the authors of the “informal note” or not?

I’ve never seen a math paper of any formality written without the authors’ names on it before.

> Two mathematicians at Anthropic studied and validated Claude’s paper, and produced an informal note for experts stating Claude’s proof concisely.

Why hide the names of the people who wrote the second paper? To discourage people from citing it instead of the LLM-derived paper?

If differential parsing of X.509 certificates is a material security concern for something, then that's a bug in that thing.

Just to be clear, OpenSSL isn't doing the wrong thing, based on the description in the blog post. The specification allows and even requires behavior similar to that.

This is uninteresting. CAs are well aware that they have to encode the subject DN and issuer DN identically to maximize interoperability. There are several implementations that require that.

If we were to make a new version of the spec for X.509 certificates, I would hope that we would eliminate all the non-UTF8 encodings so that this would be a non-issue.

Pretty much all the routers that are targeted by the ban would be OpenWrt derivatives, AFAICT. It’s basically the Android of routers, except without the Google resources.

Google Wifi Is one of the main lines that aren’t based on OpenWrt.

I don’t operate any OpenWrt-based devices.

> We have been assessing our existing processes (for OpenWrt, and especially the OpenWrt One) against NIST IR 8425A, and are now accelerating those efforts to ensure we can show that routers using OpenWrt are indeed safe and secure, as determined by independent bodies.

It would be awesome to have somebody show that OpenWrt-based routers are safe and secure. I looked into this problem about 10 years ago and my concluding was that stock OpenWrt was really questionable. Like, there is no auto-update story, but at the same time it is a giant (relative to what it should be, IMO) Linux distro full of vulnerability-laden components. This space is in dire need of a minimal security-first-from-the-ground-up alternative with a real trustworthy update story.

[I was at Mozilla during the development of BrowserID but I didn’t work directly on it. I was a huge fan of the effort.]

Besides non-obvious UI issues, there were fundamental issues. One in particular that was very hard to overcome:

Very few people would choose to hide which websites they are logging into from the identity provider. People don’t care whether their IDP can see when/where they are authenticating. That’s assuming they could even understand the issue at all. They have to trust the IDP a lot either way, and this one detail is small, counterintuitive, and even oxymoronic to most people—Trust the IDP 99%, but jump through hoops to avoid trusting them 100%? Why?

There is value in the identity provider knowing when, and from which device, and from which location, and on which websites you are using the identity. Hiding any of this from the IDP hurts security. It is really hard to overcome this in a useable way. A lot of purported solutions implicitly assume users have device and key management abilities that even experts in this area rarely consistently practice.

So, then, are you really better off, i.e. receiving a net positive benefit?

The purpose of a system is what it does.

Many implementations limit the RSA key size to 8,192 or 16,384 bits (because the maximum bit length determines indirectly how much stack space is required).

BenQ PD2730S.

Actions have special integration with GitHub (e.g. they can annotate the pull request review UI) using an API. If you forgo that integration, then you can absolutely use GitHub Actions like "a container you run scripts in." This is the advice that is usually given in every thread about GitHub Actions.

At https://rwc.iacr.org/2025/program.php you can see there is a talk scheduled to be given in a couple weeks titled "Testing Side-channel Security of Cryptographic Implementations against Future Microarchitectures" with the following bits in the abstract: "Using this framework, we conduct an empirical study of 18 proposed microarchitectural optimizations on 25 implementations of eight cryptographic primitives in five popular libraries. We find that every implementation would contain secret-dependent leaks, sometimes sufficient to recover a victim’s secret key, if these optimizations were realized. Ironically, some leaks are possible only because of coding idioms used to prevent leaks under the standard constant-time model."

Which CA's will issue short-lived certificates without negotiating a custom ($$$) contract with them?

Again, this is just a temporary situation, and a matter of burning down a list of small tasks. Not that the OpenSSL license issue is a big deal for most anyway. Feel free to help; see this issue filed by Josh Triplett: https://github.com/briansmith/ring/issues/1318#issuecomment-...

> Maybe so, but pretty much all cryptographic primitives have to be written in assembly anyway to achieve constant time operation.

This really oversimplifies the situation. Even at my most pessimistic, I believe just a very few, very small, parts need to be written in assembly language to maintain the "constant time" properties, and that's just until we can work together better with the Rust language team to eliminate these small gaps. Even before then, the Rust language team is doing a good job at independently improving and expanding the building blocks we need to get to entirely-safe (in the Rust `unsafe` sense) and high-performance crypto libraries in Rust.

> evidently faster than ring itself[1].

If you're running on an AVX-512 system, there is a notable performance gap, temporarily. This state will persist for a few months at most, most likely. It's inevitable that we (all the OpenSSL forks, and even including non-OpenSSL-forks like rust-crypto) all converge on more-or-less the same implementations and/or different implementations of the same optimizations.

I think that's a really good question. The way this worked out is worth studying in detail. What was the process with which the AES-GCM cipher suites for SSH were developed? What was the process with which the ChaCha20-Poly1305 cipher suites were developed? How did the difference in processes lead to the difference in results? Will anybody change their process based on these results?

> But it took until 2023 for someone to do the legwork to figure out how broken it was.

It took until 2023 for somebody to publicly disclose the problem.

The first fix for it was described in RFC 5647, which was published in August 2009 (first draft was submitted in June 27, 2008).

There are multiple reasons for a user to want "dark mode":

* I just want everything to be dark on my screen because I like it.

* I am trying to use this device in a dark place.

* I want a dark, low-contrast background that doesn't compete with image colors.

The solutions to these three problems are all some kind of "dark mode" but each one needs a different solution. Sometimes one "dark mode" might work in conjunction with the user manually changing their brightness settings depending on the lighting in the environment, but not many people seem to design for that.

The the old yanking policy was extra work I did with the intent to help people. It was unfortunate that Cargo had that bug, but also I should have been much more diplomatic in how I dealt with it.

I've just returned from a long break and I do have a concrete plan to catch up on the backlog. I have concrete plans for making it easier for people to get their PRs merged, making ring portable to all platforms, and eliminating all the remaining bits of C code in the next two quarters.

Feel free to reach out privately if you want to talk: brian@briansmith.org.

> Bundling this set with Firefox

I love that they did that; it was actually my idea (https://bugzilla.mozilla.org/show_bug.cgi?id=657228). I believe the list is pretty large and changes frequently and so they download it dynamically.

> short cut to a "Yes"

Do they really do that? That's awesome if so. Then they don't even need to ship the roots.

> I specifically don't like [...] saying "unknown issuer"

https://github.com/briansmith/webpki/issues/221

> If std::fs::File::open() gives me Result with an io:Error that claims "File not found" but the underlying OS file open actually failed due to a permission error, you can see why that's a problem right? Even if this hypothetical OS doesn't expose any specific errors, "File not found" is misleading.

A more accurate analogy: You ask to open "example.txt" without supplying the path, and there is no "example.txt" in the current working directory. You will get "file not found."

Regardless, I agree we could have a better name than UnknownIssuer for this error.

Are you assuming that the set of certificates that is given as input is the complete search space? It isn't; the server might have failed to send some certificate that, if present, would have fixed the "unknown issuer" problem. Also, we fail fast on errors; as soon as we find a problem, we stop the search on that path. Because of these reasons, identifying a single error would be, potentially, misleading.

In some cases, e.g. the end-entity certificate is signed with an algorithm that isn't supported, or an RSA key that is too small, we could add special logic to diagnose that problem. However, all this special diagnostic logic would probably approach the size of the rest of the path building logic itself. It doesn't seem appropriate for something in the core of the TLB of the system. Perhaps at some point in the not-too-distant future we can provide some mode with more diagnostic logic, and find a way to clearly separate this diagnostic logic from the actual validation logic to ensure that the diagnostic logic doesn't influence the result.

In a properly-designed CI/CD system, a dependency getting yanked isn't an emergency unless you choose to treat it as such. In particular, if you don't want your build to fail because some dependency got yanked then you need to use a Cargo.lock, and you need to ensure that you're not overzealous in your use of cargo-deny and similar tools.

I'm not sure if you were affected by this, but Cargo introduced a (regression) bug a couple years ago that caused it to fail when a crate got yanked when it shouldn't have. This bug was eventually fixed, but lots of people blamed ring for this bug. If this Cargo bug hadn't been introduced then most people who were using Cargo correctly wouldn't have been negatively affected by ring's old policy.

> he situation described above just generated an "Invalid certificate" message. More use of anyhow::Context would be helpful. I don't disagree with Rustls disallowing decade-obsolete crypto. It's the "silently ignores" part that's a problem.

Because of how X.509 certificate validation works, in general it's not possible to tell you why an issuer couldn't be found, because there are many possible reasons.

Regardless https://github.com/briansmith/webpki/issues/206 tracks improving the situation.

> The EverCrypt primitives are formally proven, whereas ring has no such formal proofs.

We do use some of the Fiat Crypto stuff for elliptic curve computations. I am not opposed to switching some stuff to use EverCrypt or other things that might be better, as long as the performance is the same or better, and as long as there's a clear path towards that code being in Rust.

> ring has several primitives that are assembly only and have no portable fallback.

Either in the latest release (0.16.20) or the upcoming release, there is a portable non-assembly implementation of everything in ring.

The goal of the ring project is to be much safer than OpenSSL without any notable decrease in performance. That is, my goal is to give you memory safety "for free" if you switch from OpenSSL/BoringSSL to ring. In some cases it is better than free because we end up being faster.

The assembly code in ring is some of the most heavily-tested code in the world. It's fuzzed pretty much continuously in various projects that use it, and a bunch of testing has been done on it. It is from BoringSSL, and much of it is shared with OpenSSL and/or Linux kernel. As we are able to replace the assembly code with safer code, we'll continue to do so, just like we've replaced most of the C code with which we started.

When I merged security fixes from BoringSSL/OpenSSL, I yanked the old versions of ring that didn't have the security fixes. I thought that was a pretty reasonable policy, however people who like to comment in these forums disagreed very loudly, so I stopped doing that. Not sure that's better, but there's less complaining.

In general, my initial thinking was based too much on the assumption that people would help maintain the things that depend on ring to update them to the latest release. It turns out there's less cooperative maintenance like that than I expected.

That hasn't been the case for a long time, a year or more.

There are lots of people doing awesome stuff with cryptography in Rust, including (but not limited to) the people who maintain Mundane.

You are right that ring has a much-reduced set of build dependencies compared to Mundane/BoringSSL. However, it is also true that Google implemented some build system support (to support Mundane?) that will help ring's custom build system a lot too, once I find some time to make use of it.

There isn't yet any name mangling in the C/assembly function names that would prevent collisions between two incompatible versions. I use `links = "ring-asm"` in Cargo.toml to prevent people from accidentally including two versions of ring for that reason. I am going to switch that to use a different mechanism.