nmadden

The pads are split into three pieces that are XORed to create the actual pad to reduce risk of compromise.

Thus creating a two-time pad, which is completely insecure…

Re: cheap - Anthropic’s write-up said it cost $20,000 of runs to find that bug (and a few others). So not that cheap compared to other tools - more similar in cost to human review/pentest, but probably more exhaustive.

This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.

They don’t talk about the other findings, so I’m guessing they are minor.

Crashing is not an outage.

Are you in the right thread?

MBP = Macbook Pro AW = Apple Watch? What is APP?

Not sure why you're being downvoted for recommending a classic textbook!

Because in practice, everything is finite.

Indeed! https://neilmadden.blog/2019/02/24/why-you-really-can-parse-...

100% reproducible deterministic bugs are absolutely the easiest class of bugs.

The proprietary/commercial TALA engine is really excellent too. I’ve been using it to do complex dataflow diagrams, and the results are so incredibly well laid out.

I guess. But it would only impact you if you’re using cookies with curl (I assume the middleware is only applied to requests with cookies?) — and it seems pretty easy to add a -H ‘sec-fetch-site: none’ in that case.

The article has a whole section about requiring those headers by forcing the use of TLS 1.3 — the theory being that browsers modern enough to support 1.3 are also modern enough to support the headers. But why not just enforce the headers?

Enforcing TLS 1.3 seems like a roundabout way to enforce this. Why not simply block requests that don’t have an Origin/Sec-Fetch-Site header?

Yes, of course it’s (largely) subjective. But I have actually read much of the source code of Spring. I know it _very_ well.

Java is sprawling now. It wasn’t 26 years ago.

Yes, in theory they are good. In practice they cause enormous amounts of pain and work for library maintainers with little benefit to them (often only downsides). So, many libraries don’t support them and they are very hard to adopt incrementally. I tried to convert a library I maintain to be a module and it was weeks of work which I then gave up and reverted. As one library author said to me “JPMS is for the JDK itself, ignore it in user code”.

Given how much of a coach and horses modules drove through backwards compatibility it also kind of gives the lie to the idea that that explains why so many other language features are so poorly designed.

Do you really think that in 26 years of professional Java programming I’d have never touched Spring? I’ve been using Spring since it was first released. I’ve found CVEs in Spring (https://spring.io/security/cve-2020-5408). Trust me when I say that my dislike for Spring (and annotations) is not based on ignorance.

The first day I used it, Claude got stuck in a loop trying to fix a problem using the same 2 incorrect solutions again and again and burnt through $30 of API credits before I realized things were very wrong and I stopped it.

The worse it performs, the more you pay. That’s a hell of a business model. Will users tolerate that for long?

The improvements in programming are largely due to the adoption of “agentic” architectures. This is really a hybrid neural-symbolic approach: the symbolic part being the interpreter/compiler. Effectively the LLM still produces an almost-correct-but-wrong program and then the compiler “fact-checks” it and then the LLM basically local-searches its way from there to something that passes the compiler. (If you want to be disabused of the idea that LLMs on their own are good at programming, just review the “reasoning” log of one trying to fix a simple string | undefined error in Typescript).

It seems clear to me therefore that further improvements in programming ability will not come from better LLM models (which have not really improved much), but from better integration of more advanced compilers. That is, the more types of errors that can be caught by the compiler, the better chance of the AI fuzzing its way to a good overall solution. Interestingly, I hear anecdotally that current LLMs are not great at writing Rust, which does have an advanced type system able to capture more types of errors. That’s where I’d focus if I was working on this. But we should be clear that the improvements are already largely coming via symbolic means, not better LLMs.

I wrote some notes about a year ago about the irony of LLMs being considered a refutation of GOFAI when they are actually now firmly recapitulating that paradigm: https://neilmadden.blog/2024/06/30/machine-learning-and-the-...

This was before LLMs. It was a combination of unit and end-to-end tests and tests written to comprehensively test every combination of parameters (eg test this security property holds for every single JWT algorithm we support etc). Also bear in mind that the product did a lot more than just OAuth.

Adding some OAuth helps a bit: https://neilmadden.blog/2022/01/20/why-the-oauth-mtls-spec-i...

(I quite like the combo of app-level OAuth plus mTLS service mesh for backend comms).

CBOR is basically a fork of MsgPack. I prefer the original - it’s simpler and there are more high-quality implementations available.

Yes (although practically speaking it’s very unlikely that Grover will ever break AES-128), but that’s still a brute force attack and still subject to the physical limits mentioned in the Schneier quote. Whereas attacks on RSA like the number field sieve or Shor’s algorithm are much more efficient than brute force. (Which is why you need such big keys for RSA in the first place).

That’s true for AES-256. But brute force attacks are not the most efficient way to attack RSA, so it’s not true in that case. (Eg quantum computers would break RSA-4096 but not AES-256).

Yes, the WebAuthn spec is pretty unreadable. Every time I open it I feel like I’m lost in a maze of twisty hyperlinks, all alike.

Have you ever attended an all hands that couldn’t have been an email?

Indeed, modern ML has been a validation of (some of) GOFAI: https://neilmadden.blog/2024/06/30/machine-learning-and-the-...

Exactly that. (Hijack session rather than account: any competently designed system should require re-auth before any action that would allow permanent account takeover).

each assignment is creating a new scope

No, it’s rebinding the variable within the same scope. Even if you view it as implicitly creating a new scope, the implicit part means it can happen on any line so you have to scan them all and mentally keep track of what changes where, (almost) exactly as you would for imperative code.

The ellipses in your straightforward transformation are doing some heavy lifting there. Typically the let…in construct has some way to indicate where the scope of the “in” part ends: indentation (Haskell), explicit “end” marker (SML) etc. Even with that, shadowing does make equational reasoning harder (you have to look at more surrounding context) and should generally be avoided.

The example given in the article is:

    counter = 0
    counter = counter + 1

OK, sure. As far as I’m aware, nobody’s actually made that into an actual AKEM proposal though. (I wish they would, as I think many applications would be fine with pre-quantum authentication and post-quantum confidentiality).