I feel like this article spends a lot of time on metaphysical speculation (what is "real"). However what i am left wondering is what exactly would the consequences be if this theory was true (for those of us living in a holographic universe).
I think the point of the person you're responding to is what are the practical consequences for future scientific and technological leaps if this is accurate. Does that make FTL travel possible? Does it predict an outcome for the fate of the universe? etc.
i dont even mean big things like that. I'm more wondering, is there any experiment you could in theory do that would differentiate between the two cases? what does it affect? anything?
I thought it was a really good, clear write-up of a very nice engineering discovery and optimization. If anything, I think an LLM would generate native superscript for the `2^(-r)` expression, so I didn't have an impression of LLM authorship.
Maybe an LLM did the search for what expressions to put in the blocks vs tail of the vectorized collision detection, but that seems like a good place to use an LLM as long as all of the expected bit relations are verified as checked properly.
Hi, author here. FWIW the blog is fully hand-written. I used Claude to help me generate the visuals.
What goes into head vs. tail is actually fully deterministically decided by the solver based on a P(tail) gradient, so expressions that are more effective in filtering out blocks before they can hit the (slower) tail are preferred in the prefix.
Its seriously such a cheap, easy, and lazy accusation to make by just accusing it of being slop, I actualky hate the slop-accusing more then any slop. Any bot can just randomly say slop and in at least someones eyes a whole writeup will have been discredited thru tho fault of the author.
It needs to stop, if people have a factual or actual valid criticism of the facts or claims then by all means, go to town. But Im done with the slop screamers, its a downvote and scorn all the way down for those
> The security for SAML is baked into the payload itself, provides safety against MITM attacks, even though the HTTPS provides similar guarantees in theory, the reality is that your SSL offloading happens elsewhere, not on your application server
This is just as true for JWT. Actually its a lot more true for JWT as people usually implement this wrong in SAML.
Additionally, https doesn't really protect you here, as typically the user sees the token/saml document, and they are the main party you have to worry about being in the middle.
> this kind of comparison if flawed if you do not present the same for OIDC/OAuth2.
i'm doubtful there are any vulns in oidc/oauth2 that aren't present in saml. SAML vulns are typically a strict superset of oidc vulns.
I feel like there is an easy solution to login csrf with IdP initiated flows. The SP just gives a pop up saying - you are logging into X as user Y. Continue?
The has been proven again and again to not work. See for example HTTPS certificate warnings for which now there is a standard to ask browsers to not show a popup just saying "The server might not be the correct one. Continue?"
It's an easy solution, but it doesn't work at all.
OAuth2 is about a billion times better than SAML. At least you have a decent chance of doing it securely if you follow the spec vs about zero chance with saml.
My favourite SAML horror story, is that it used to be, that by default the main c implementation of xmlsig would not just check the sig with the public key specified but would also:
- check it against an hmac using a password specified in the attacker controlled document.
- check the signature using web pki (so the attacker could sign the saml document with their TLS key for their own personal domain and it would always be considered valid)
I honestly dont know how sites with saml arent getting hacked all the time. The only thing worse than the absolute terrible standards are the absolute terrible implementations.
I saw multiple implementations that looked for a signature, verified it, then just trusted the document as a whole rather than only the part that was signed. So as long as you had any signed SAML doc, you could provide an attention of your choosing and just bundle the signed one somewhere arbitrary inside of it.
It’s also enormous, I assume from the attempt to have nominally composable parts that could be reused for other flows.
It’s three entire specs bundled as one. One for the XML components, another for the documents you build from them, and another for the authentication flows built on top.
It is truly surprising how large the specs for each of these ecosystems are: PKI, Kerberos, TLS, OAuth, SAML, etc. They are gargantuan, especially when you include essential dependencies like DER codecs and ASN.1 compilers (PKI, Kerberos) or XML (SAML).
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
The problem with this is the assumption that there's a simpler way to do all of this, and if only we could stop looking for large and complex solutions we could just land on the simple ones.
I listed a number of solutions, all built by different people, at different times, in different orgs, and some of those solutions (OAuth, SASL) being much more organic in how they evolved, and yet all are ultimately large and complex.
I think that hints at the problem space being... large and complex and requiring large and complex solutions.
What we _can_ do is avoid adding complexity unnecessarily, but what looks like a simplification today (e.g., picking the best current encoding system) might look like a terrible mistake in twenty years.
The thing is that they don't have to be that big at all, you could probably specify enough of PKI and TLS and SSH to cover most uses cases in, I dunno, 30-40 pages. However the standards bodies that produced them, termed "working groups", are more like standing committees that will (a) standardize any random idea that any member brings along and (b) are worse than the energizer bunny, they just keep going and going and going and going. Even ones that have been forcibly shut down like PKIX just keep going in other forms (LAMPS). You can't stop these standards mills, they'll just keep grinding out more stuff that no-one ever asked for, for all of eternity.
It sure sounds like it should be like this, but when you actually try you end up with not this. TLS is huge! Yes, but SSL 2.0 was smaller, and buggy as hell, so it had to evolve, and after 30+ years it became the monster that it is today.
Of course, SSL 2.0 did reference x.509, so hey, SSL 2.0 should have invented its own PKI. Except that Netscape might have come up with something terrible that worked in 1993 in labs but didn't scale to the web, or just full of security problems, or...
What you say sounds nice and right right up until you actually look at the details of what actually happened in real life, and how things actually evolve when they have little standards involvement.
Well, no-one held a gun to their head but there was a general "enough, already", aided by the fact that several of the main characters were retiring which helped wind it up. And then they just kept going as before under a new name and with an influx of new people who were unaware of how the original mess was made and why.
So if a WG is wound up and then continues under another name with mostly the same people doing the same things the original WG did it's not really wound up, is it? It's just changing the sign over the door with business continuing as usual.
First, anyone can participate. The only cost is the value of your time.
Second, yes, there are the usual suspects -- the ones who've decided to spend a lot of their time on whatever the area of tech we're talking about.
Third, working groups have charters that delineate what RFCs they will publish. Sometimes the work runs out. Sometimes the people run out of energy. Sometimes the tech is 'done', at least for a while. Then the WGs shut down.
Fourth, sometimes new work gets brought to the IETF in an area where the relevant WG has concluded, so then a new WG _may_ get spun up to take on that work.
The root problem with SAML is there’s a million and one permutations to do the same thing.
Signed assertions. Signed messages. Encrypted messages. Encrypted assertions. Sign after normalization. Sign before normalization. Encrypt then sign. Sign then encrypt.
That's because its built in part on XMLDSig, a genius idea to sign active content that can redefine its own semantics as it's being signed/verified. It's a triumph of ideology over common sense.
The first book that came out on XMLDSig, "Secure XML: The New Syntax for Signatures and Encryption", written by the chair of the working group, spent over half of its 500 pages wrestling with canonicalization, and even then it read more as a 250-page problem statement than a solution.
And that was before you got into deliberately malicious content that actively subverts the signature process.
I say this a lot, but: there was a conspiracy theory that NSA had infiltrated the IETF during the original IPSEC standardization effort and injected the "TLS BEAST" CBC IV chaining vulnerability, which is funny because we actually know exactly how that happened (professional academic cryptographers took out a petition to get the bug fixed and were shouted down by standards body gadflies who literally rejected the premise that there was such a thing as a professional academic cryptographer). This is really easy to see once you've done an engagement on DSIG security! Standards bodies are more than capable of fucking things up entirely on their own. If anything, NSA would risk making protocols stronger by intervening in their natural processes.
"Never attribute to malice what is adequately explained by stupidity". Or, in this case, design-by-committee by a bunch of people who haven't written ten lines of code in as many years. There have been several other cases where absolute no-brainer fixes, like one or two lines of code changed, to long-standing security problems, were filibustered, or blocked by WG chairs, for no explainable reason, and they can't all have been paid by the NSA to do that.
Yes, absolutely. And it's self-selection for mediocrity, people who are useless at any other task and prepared to argue endlessly over pointless technicalities that no-one apart from other professional meeting-goers care about are perfect for dumping onto standards committees.
This is a pretty common implementation error. You can just add your own assertion that overwrites any claims in the signed assertion (such as username) and use it to escalate privileges or take over any account that you like.
JWT has two out of the three issues mentioned above:
1. It has the ill-conceived "alg": "none". But this feature made breaking JWT so easy and low stakes, that many libraries have removed this feature completely, or just disabled it by default.
Modern RFCs that mandate JWT use in servers (e.g. RFC 9068) often explicitly forbid this, and the latest BCP for JWT (RFC 8725) recommends that libraries only accept or generate tokens with "none" when the user _explicitly_ requests that. And yet, we're still seeing "alg": "none" vulnerabilities even to this day. I'm not sure if it made sense to support "alg": "none" in the first place, but if we ended up doing that, the RFC should have been much more strict about this.
2. The other issue is mixing up asymmetric and symmetric encryption. You can't embed the HMAC password directly in the user-generated message; but if the library is not built securely, it would just treat the public key itself as the HMAC key when it gets an HMAC alg in the header. This makes forging tokens quite trivial if the library is misconfigured.
JWT is not nearly as bad SAML and its designers learned some important lessons (simpler base format, no canonicalization or embedded signatures), but this is still a design-by-committee standard that didn't properly involve. The full JOSE standard (including JWA) is even worse, but fortunately JWA doesn't get used a lot.
Yeah I wanted to use alg none for some unit tests once (it was easier than setting up the next lowest tier security option) but whichever Java library I was using had completely disabled it. I could see it had been supported at some point but it had been updated so that it couldn't be enabled at all.
Yeah, the standard should have just specified like a sha256 HMAC, when that becomes broken in 20 years we can just do a JWT2 (or invent some new successor standard)
given that md5-hmac isn't even broken despite md5 being broken, it seems unlikely sha256-hmac will fall in 20 years.
that said, algorithm agility isn't the primary issue, its whether you want symmetric (hmac) or asymmetric (digital signature). Both have advantages and disadvantages so there is no per-se right answer, it depends on context.
Yes, but you shouldn't be taking instruction on how to verify the security of a JWT from the JWT itself in the first place. Don't follow an attacker's security steps.
In SAML you sign a (potentially attacker controlled) subset after normalization. So a lot of saml bugs come down to the attacker adding things that aren't covered by the signature. Sometimes this means appending or prepending stuff, but my favourite is adding comments which can alter the interpretation of the xml document (as it splits text nodes) but doesn't alter the signature.
reply