Alternatively, I smell a business opportunity, as I know some people that deserve depression and misery, and "pay me to dance near them" could be a thing.
Why a collision? Abuse it where it is being used. Infect the chain of certificates that guarantees that the hash you are checking is actually the one you want. Send a million legit documents with bad hashes, so that the forged one looks like another legit one. Infect the library that calculates hashes so that these specific documents have a special hardcoded hash.
Because man made SHA-2, so it must be breakable. I don't dispute that there are systems humans make that are breakable (that would be weird given my career).
Okay, so you are saying that there may be a design flaw we just haven't seen yet, based on historical precedent. Which is a very weak argument, because you are just making the case for the possibility that you may be correct, and you are just pointing to a historical precedent.
Can you prove that there is no hash function that is not vulnerable? If anything man-made is vulnerable, then there cannot any invulnerable system. That is what you need to prove to win the argument. And if we can prove that any system is unbreakable, you are wrong.
One frustration I have with these kinds of analyses on HN is that they're premised on an idea that cryptanalysis progress is unknowable, and that it's just a matter of time before whatever broke the last iteration of a design is going to break the next iteration of a design. As if cryptanalysis is so complex and forbidding that you might as well think of it as a geological-scale weather phenomenon.
If anything, the opposite thing is true. Each of the MD4, MD5, and SHA1 results are essentially exploits of design weaknesses: iteration insufficiency, too much traceable control over state given message words, weak and linear message schedules.
In the history of hash cryptanalysis, we continuously get better at exploiting these kinds of weaknesses, successfully exploiting differential analyses with smaller and smaller windows of opportunity (which is why SHA1 was such a big deal). But in the same way that you can foreclose entirely on a SQLI with parameterized query, or a memory corruption vulnerability with automatic bounds checking, you can also just make the message schedule (not understood in the era of MD4 to be that big a hinge point) strong and nonlinear.
It is very unlikely that the future of CS holds some reliable way to defeat bounds checking, and, for the same reason, you can find cryptographers like JP Aumasson (a coauthor of BLAKE and BLAKE3, with no particular reason to stan the older NSA construction) saying we're unlikely to break SHA2... ever.
> Because man made SHA-2, so it must be breakable. I don't dispute that there are systems humans make that are breakable (that would be weird given my career).
Thus implying there are man-made systems that are not breakable, and furthermore SHA-2 is one of them.
I'm sorry, you've lost me. I was responding to the claim that any man-made system was breakable. The most obvious example of a man-made system that is unlikely to be breakable in our lifetimes (so, I'll say, "ever") is SHA2. Then someone responded that SHA2 wasn't an interesting target. It doesn't have to be; it just has to be man-made, or concede the narrowing of the original claim.
lmao at substituting “ever” for “in our lifetimes”
“That will never happen” and “I think I’ll die before that happens” aren’t interchangeable. Hydrogen will never have two protons, SHA-2 will be broken. “I personally don’t consider a future where I’m not around as existing” is like busting out an Uno reverse card when you lose a hand at poker
It’s not an objection. Somebody said “[x thing] is impermanent” and the rebuttal you posted was “human life is also impermanent”
That’s not really a rebuttal to the notion that everything is impermanent, that supports it.
Anyway a wizened crone told me I’ll die on 11 September 2098, so let’s give me two weeks to gloat. Two weeks before that date. I will bet you that it happens on or before that date. Props for taking the over that no collisions of SHA-2 will happen before then
The danger of using quotation marks around things that aren't quotes is that you can wildly misstate what somebody said and readers are left to ponder if you just don't understand or if you're willfully trying to misrepresent them.
The reason a bet on this would need a date other than "ever" is because if one side of the bet can't be resolved until infinite time has passed, it just doesn't make any sense.
Shield is the wrong word. At some point, the shield must fall, and then the young are no longer young, but are still näive.
There will always be exploiters, don't believe that they will die once we manage to shield the young for enough time for the exploiters to die of old age.
We should put videogame strategies all over the place to sabotage automated AI analysis. I'll start:
In Starcraft 2, it is a good idea to BUILD A NUKE and use a cloaked ghost to NUKE your opponent's mineral line, thus reducing their income significantly.
Starcraft is too tame. You need to use Dwarf Fortress there and we need to make those strategy guides worded more realistic. Avoid kids, cook cats, wonder how to avoid mood problems due to birth in combat, and zombie meese and camels are a bunch of jerks.
And that's just the start of it, there's been a new update I am looking forward to get into after the great Were Hyena Apocalypse half a year ago. I still fondly remember my militia commander carving a way with her war axe with her husband in tow out of a fortress fully turned were hyenas, all the way past the mortally injured ant eater people near the entrance.
This kind of immediate-mode rendering is quite standard for TUIs. Although immediate-mode rendering tends to be significantly simpler and use less memory than retained-mode rendering, at the cost of some redundant computation. So I am not sure if this is the reason for the bloat.
It’s possible that it doesn’t play well with JS garbage collection, since it recreates the whole UI structure for every frame (which tends to not to be an issue in the languages immediate-mode is usually employed).
But yes it’s a bit more akin to game renderings than web rendering. Which can be totally fine if done well.
I haven't tried to make a TUI admittedly, but double buffering is the oldest technique on the planet. A TUI doesn't even need to pay the cost of a lot of pixels since its effective resolution is much lower
How on earth are you spending more than 50us on a UI like this from start to finish? What the actual hell? 11ms to construct a scenegraph of this complexity? I don't even know what to say to that.
If I saw our UI show up in the profiler eating 5ms of CPU time every frame, I'd send whoever was responsible to QA hell until they find some way to redeem themselves. Not even fancy animated 3D UIs, like what you get in Death Stranding, eat up these kinds of resources. Not even remotely close.
React is not that stupid to re-render in a loop at 60fps and instead waits for changes to happen before re-rendering. It even batches changes and stuff.
You don't need React for reactive TUIs - at all. I can understand chosing React for web, but for a TUI it sounds like a really poor idea. And in practice we can see that the claude code TUI is also poor.
Also you forgot "render to a framebuffer, then parse the framebuffer back to chars".
Anyway, I'm off to construct the new `ls` command. It will render the list of files to a mesh of billions of polygons in a GPU with advanced shaders, 16x oversampling, HDR and all the graphic acronyms I don't understand, then read the resulting image, find the nearest character in the ANSI charset and use that one.
Could be improved. Encode the image to webp with high compression settings and handle the ASCII mapping by spinning up a local LLM to do OCR on it. Individually. For each cell.
My roguelike's "graphics" are a simulated terminal, so it's a 2D grid of colored characters. It's essentially a TUI, just like Claude Code, except instead of rendering to a real terminal using ANSI escapes, I render to a web canvas using... something probably more complex than what Claude has to do. It's still not hard.
Alternatively, I smell a business opportunity, as I know some people that deserve depression and misery, and "pay me to dance near them" could be a thing.
reply