Reading the blog, it sounds more like they were depending on libraries (both by Cyphernet, interestingly) and implicitly trusting them, instead of verifying.
Which I can understand to an extent with large, high-traffic dependencies but these were really low traffic projects with like 10 stars on github and barely any development... Well, hindsight is 20/20.
It's unfortunate that write-up is AI generated ("Here's the catch... And this is the part that honestly surprised me" tipped me off, and Pangram cites it as 100% AI too), because it's hard to understand what's happening.
It looks like the Noise API can be confusing. They tried to implement it, got the handshake and key exchange right, but then used Noise API calls intended for sending raw data directly to the wire without the encryption they set up? So keys were exchanged, then never used?
I think the core problem isn't that the Noise "API" is confusing, it's that Noise is a framework for building reasonably-secure protocols. If you don't know how to build or evaluate cryptosystems, you shouldn't assume that just dropping in a library will somehow make your novel network protocol secure.
"Don't roll your own crypto" gets a lot of lip service (and a fair number of eye rolls) but it's really, truly something worth considering because it isn't just the algorithms or libraries you choose: it's about the whole package, including things like wire serialization, internal handshakes/security, etc. Just grabbing a Noise tutorial and building your own implementation is a Bad. Idea.
And this is only getting worse now that people can prompt their way through building a "secure" system only to realize they really didn't understand what that means. No amount of Markdown saying, "don't introduce a cryptographic vulnerability in this code" is going to save you if you don't know what to do in the first place.
But also: the vulnerability was literally visible using basic Wireshark/pcap traffic sniffing. I'm sorry, but if you don't even bother (or know how) to do that kind of basic security analysis you should stop and look for someone who does to check your system in the real world before you tell people to depend on it for serious work.
(That being said, if someone had just typed 'find me a vulnerability in this protocol' in a code agent backed by Fable or Astra with any kind of access to network traffic dumps it probably would have taken about 15 minutes to discover this issue. Might even be significant part of how the above author found it, given the other LLM-ish fingerprints in the writeup.)
Equating memorizing import paths - something IDEs have been doing automatically for decades now - to 'basic ability' might be the dumbest thing I've read this year.
It's a valuable skill to recognize which knowledge is important, and which is fluff you shouldn't waste cycles on. Knowing what a hashmap is useful for, when to use it, and when it's suboptimal, is important. Memorizing import paths is not.
Okay, I've done that. The only thing I can think of to specifically look at is the ID fragment. I see the same ID in the archived thread on reddit.com and the archived thread stored on github.io (I'm not sure which source to disambiguate "archived thread" to).
My point was/is that the threads are identical, and given the different titles points to an supposedly-impossible ability to change thread titles. This is very interesting to me.
In case I'm [still] missing the point you're trying to get at. Further clarification and patience is appreciated.
he explained the point. The archived copy has been redacted, the whole reason the archive exists (and the original deleted) is because its impossible to redact the information on reddit while leaving the rest of the post intact.
Which I can understand to an extent with large, high-traffic dependencies but these were really low traffic projects with like 10 stars on github and barely any development... Well, hindsight is 20/20.
reply