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.