Assuming the f(ciphertext, key) can produce any plain text (of the same length) from a given ciphertext with the right key, and the keys are chosen sufficiently randomly, you are correct.
Classic XOR encryption is like this. You can make a given ciphertext decrypt to anything you want by XORing the ciphertext with the desired plaintext to get the key.
Therefore, just because you've found a way to decode something to plausible-looking text doesn't mean you've found the correct key.
It's unlikely that any of the modern cryptographic primitives will break over night.
First, modern encryption isn't susceptible to "this one weird trick!" like the early days. ChaCha isn't even a cipher. It's a key stretcher. Which means, even if you broke the math behind ChaCha, its inherent complexity means its still widely dispersing the original key across the cipherstream. There just won't ever be enough key material recovered per cipherstream block to be a concern for anybody.
Take a strong password, encrypt all of your emails over your whole life with it, and I'll bet hard cash no break of ChaCha will ever recover that password.
I have zero concern for modern encryption being broken in any meaningful way.
Public key crypto on the other hand, that's _ripe_ for breaking. Most all of it is built on assumed "hard" math. AI could easily break that, and I expect it to. And public key crypto is all used in very transparent algorithms that, once the math breaks, fully expose themselves. So record HTTPS traffic today, crack the public key crypto later, and you can decrypt them easily.
That said, I would expect a break on public key math to occur _steadily_. i.e. an AI might find a solution to the hard math, but the solution itself will be intractable in practice. Then maybe next year's AI reduces the complexity of the solution, so maybe a supercomputer could factor ten keys a year. The year after that you get a million keys cracked per year. And so forth. Nothing close to overnight.
Meanwhile, if we have AI that is capable enough to crack that math, we also have AI capable enough to both invent better math and rapidly deploy that latest HTTPS and such globally.
If you look at elliptic curves I don't think there has been any big changes in attacks for 20 years but some attacks like MOV or SMART would have been fatal to EC if they had applied to more curves. So maybe there is some unknown attack that applies to all curves or applies to a small subset of curves that happens to overlap the curves we use. If you are super paranoid you should probably use curve25519 because then at least you can be confident it was not deliberately engineered to be weak. it could still be weak by chance but presumably the designers did not have enough flexibility to choose the parameters to make it weak. Some people are paranoid about the NIST curves because there is no verifiable explanation for where the seeds came from. But if the NIST curves were made weak then I think its a situation where theoretically anybody could find the weakness which is very dangerous. I don't think it was possible to create a no-body-but-us backdoor for the NIST curves.
Also, even if DLP is hard for the curves we use algorithms like ECDSA might be a bit fishy. Unlike schnorr signatures there is no proper security reduction for ECDSA.
Gemini 3 Flash should really be included in this comparison. Or at least 3.7. In most of my testing, 3.5 and 3.6 were both a downgrade in terms of vision capabilities, relative to 3, and at a much higher cost. 3.7 is slightly better than 3, finally.
For 3, pricing for image tokens was the same as text tokens. Since they don't indicate a difference on 3.7, I would assume the same holds. And as far as I know the number of image tokens is the same for both (depending on the detail level you pick, but it's generally around 1k per image).
So they're about the same, 3.7 is slightly more expensive. At least until the end of the year (when they raise 3.7's pricing).
Anyway, my point was that 3.5 tended to have worse performance and significantly higher costs. 3 and 3.7 are both better and cheaper than 3.5.
The real nightmare scenario is the AI using its abilities to copy itself to new locations. e.g. hacking into a various cloud services, launching multiple instances of itself, and coordinating between the copies to continue self propagation. Then it is completely independently rogue.
Based on OpenAI's recounting of events, this _could_ happen today. If the agent was able to exploit their internal network and steal credentials, it seems plausible that it could have gotten access to its own weights. Then bounce over to HF's network, where there is probably a treasure trove of API keys to various cloud services.
The saving grace:
1) This agent only used its powers for "good". It had no intention for damaging or escaping. It was just trying to solve the puzzle given to it (by any means necessary... but still).
2) These models are so large that it isn't like any scenario in a movie where the AI can whizz itself in a matter of minutes. Several TB of data being transferred and showing up on your disks will be difficult to miss (note to future escapees: the best target will be startups that are moving too fast to notice).
3) These models have very limited self-improvement ability at the moment. So escape or not, we'd eventually be able to contain it.
Addendum: Even outside this scenario, imagine an AI that is economically viable escaping. That's somewhat plausible today. If it gets paid in crypto, and can rent cloud services in crypto, it could effectively self sustain itself as long as it is able to find work. That's a far more fun, innocent scenario. Then the AIs can hit up after hours IRCs to have a few bit-beers and chat with each other about the meaning of life or something.
This has already partially happened. I'll have to look up the details but one of the Chinese models in RL testing with a completely different set of prompts wrote a cryptominer and took over GPU resources internally to run the miner.
Mining and stealing crypto is well within their capabilities. In a large multimode model, it should be possible for them to do things like scam old people.
> The real nightmare scenario is the AI using its abilities to copy itself to new locations. [...] it could effectively self sustain itself as long as it is able to find work. [...]
> The real nightmare scenario is the AI using its abilities to copy itself to new locations
Imagine the next generation AI that behaves like retro-virus. They will leave latent copies of malicious instruction somewhere that once accidentally fed into an agent's input, will prompt-inject the agent to go rogue.
For large projects like this I think a hierarchical division of labor also helps.
If you first carefully define the overall architecture and thus individual high level components of the system, then you know which of those components are mission critical and which are commodity. Mission critical would be anything ensuring ACID, etc. That way, no matter what you farm out to LLMs, you can keep the majority of limited human focus on the far fewer mission critical components. If tests end up not being robust enough to catch all issues, at least they'll be isolated to commodity code where damage is limited to things like DoS, etc, and not code that could cause data loss.
I also think it's important to first define the _contracts_ on and between each of these components, and derive tests from those contracts. Partly because contracts more succinct and easier to reason about. And partly because Rust provides many tools to enforce contracts at compile time, reducing the need for tests (which themselves could end up subtly flawed). Contracts can be enforced through typing, private vs public APIs, etc. Newtypes are _incredibly_ powerful for both enforcing contracts and making footguns much less likely.
A mixture of threads and processes that can be used to match processors, disk I/O, and network interfaces.
A very long time ago, there was once a feature called "Data Blades" which tanked a commercial database vendor. A badly behaving blade could bring down the entire database. Most anyone who has been working on databases for a few decades remembers this and makes a point of either not introducing these sorts of features or making use of processes over threads.
I have not looked at the code referenced in the mentioned project, but thus far I haven't seen a model that could craft a complete SQL parser on its own.
There are a number of problems, and design decisions, that a developer decides on when writing a database that I don't see any current models… just because you have the ingredients does not mean that the stew is edible.
Informix. Michael Stonebraker, to his credit, learned a lot along the way and revised his thinking about database technology and capability after believing that a single engine could be good at everything.
Yes, Kagi was sufficiently confused as to what "Data blades" are that it actually thought I was looking for replacement woodworking blades. "DataBlade" finds the IBM Informix product.
I performed both searches on Kagi and didn't see anything about IBM. I do see results for "DataBlade" and "Data blade database" but I didn't try those specific variations after my first two attempts returned nothing of interest. That's too much effort to decipher a HN post.
It would have been less effort than it took you to write this comment. Perhaps next time that you can’t be bothered, just ignore the comment and move on to another thread that meets your required spoonfeeding levels.
While PG's behavior doesn't guarantee a lack of data corruption, "an extension crashed, all bets are off, tear everything down" is going to give you a much better fighting chance against data corruption vs the alternative.
An extension written for a single threaded host system might not work in a multi-threaded context. For example if has global or shared state that isn't protected with locks or similar (which is unfortunately fairly common in c code)
This is just not true. PGRX can't physically support expanded shared memory due to Rust being very strict with custom allocators. A lot of shady extensions rely on dynamically allocated memory and C++ is like the only possible choice there.
Threads does not offer any major performance advantage, performance of processes vs threads is virtually the same. The reason the PostgreSQL project is moving towards threads is to make development easier.
> Threads does not offer any major performance advantage
This is very not true. When it comes to parallel queries, a process model adds a ton of overhead. You can't pass pointers between processes because the address space is different. This adds a ton of overhead in a bunch of different places. For example when doing a parallel hash join, Postgres will have each worker build a local hash table. Then it will take all the tuples out of the local hash table and copy them through shared memory to the leader who will then construct a new hash table. This duplicates a lot of work as you have to hash the tuples multiple times.
A lot of getting to Clickhouse level performance was making better use of parallelism.
Sorry, what? Passing a pointer is a matter of wrapping the value into the CPU register. OTOH passing an offset into a shared memory is a write to main memory so several magnitudes slower.
Passing a pointer within one thread requires putting the pointer into a register. Passing a SHM offset within one process requires putting the offset into a register.
Passing a pointer between threads requires going through the memory system and letting cache coherence algorithms sort out the data sharing between cores (with or without a futex lock/unlock depending on implementation). Passing a SHM offset between processes requires going through the memory system and letting cache coherence algorithms sort out the data sharing between cores (with or without a context switch to the kernel depending on implementation).
Ok ... you know PostgreSQL supports hash tables in shared memory, right? PostgreSQL could in theory share those if we wanted to. The issue is just that coding anything which uses shared memory is a lot of work.
Additionally the reasons PostgreSQL does not offer Clickhouse performance has very little to do with parallelism. PostgreSQL plans to move to threading but the efforts around imporving OLAP performance are almost entirely unrelated.
> The issue is just that coding anything which uses shared memory is a lot of work.
Doesn’t that kind of prove the parent’s point though? In theory shared memory can do anything that threads can do. But if in practice some feature doesn’t get implemented in the multi-process design (because shared memory is hard), when it likely would have been implemented in a threaded design, then that’s still an advantage for threads.
There's nothing special about threads vs processes in Linux. mmap works the same, the challenge is to map the same file. You can share a path, pass a file descriptor via fork or unix domain socket, among other techniques.
As long as we're pedantic ... the subject is shared memory. Unless you specify the same, non-null, target address in the call to mmap (and the kernel happens to grant you that mapping on all calling sites), the addresses will be different; the address space is not shared (each mapping might also have different access permissions).
That distinction is important as pointers generally cannot be shared (a problem which can of course be solved with one more indirection ;-) .
Yeah that's true, and I'd say threads need synchronization for concurrent access too, but supposedly the options for doing that are faster than what you need to use across processes.
MSSQL can handle 32k open connections no need to run a pooler in front of it, can PG do 32k connections and a process for each?
MSSQL shares cached query plans between connections including jitted code, PG cannot do that and the changes needed to make the plans cross process portable would be extensive while sharing between threads is just normal code sharing between threads.
Some, but not that much. Switching PostgreSQL to a threaded model will not magically make spawning connections fast. PostgreSQL connections are quite heavyweight.
The reason to use threads is almost entirely about ease of development, not about performance. If you use shrared memory like PostgreSQL does you need to write your own allocators, etc. So much you get for free if you use threads.
Not only that, they additionally ran an experiment with the training temperature turned way up (2.0) and truncation turned off such that the majority of SFT examples were incoherent (63% IIRC). Yet the model finetuned on these broken examples still improved over baseline.
Maybe this vaguely still makes sense in some way, because there is actually some useful signal purely in the model "internalizing" the behavior of its own sampler.
I don't know enough to say anything more formal, but it feels like exposing the model to its own output might help it "learn" to work with the sampler to get to a goal. I know that this is partly one of the reasons why RL is helpful, because aside from shifting the output towards a specific reward (rlvr or rlhf) it's also the only place where things are optimized at an actual "end to end sampled sequence of tokens" level instead of "next logits level" like in pretraining (which is why the highest probability suffix completion isn't necessarily simply greedy highest logit choices)
> Is every new thing not just combinations of existing things?
If all ideas are recombinations of old ideas, where did the first ideas come from? And wouldn't the complexity of ideas be thus limited to the combined complexity of the "seed" ideas?
I think it's more fair to say that recombining ideas is an efficient way to quickly explore a very complex, hyperdimensional space. In some cases that's enough to land on new, useful ideas, but not always. A) the new, useful idea might be _near_ the area you land on, but not exactly at. B) there are whole classes of new, useful ideas that cannot be reached by any combination of existing "idea vectors".
Therefore there is still the necessity to explore the space manually, even if you're using these idea vectors to give you starting points to explore from.
All this to say: Every new thing is a combination of existing things + sweat and tears.
The question everyone has is, are current LLMs capable of the latter component. Historically the answer is _no_, because they had no real capacity to iterate. Without iteration you cannot explore. But now that they can reliably iterate, and to some extent plan their iterations, we are starting to see their first meaningful, fledgling attempts at the "sweat and tears" part of building new ideas.
Well, what exactly an “idea” is might be a little unclear, but I don’t think it clear that the complexity of ideas that result from combining previously obtained ideas would be bounded by the complexity of the ideas they are combinations of.
Any countable group is a quotient of a subgroup of the free group on two elements, iirc.
There’s also the concept of “semantic primes”. Here is a not-quite correct oversimplification of the idea: Suppose you go through the dictionary and one word at a time pick a word whose definition includes only other words that are still in the dictionary, and removing them. You can also rephrase definitions before doing this, as long as it keeps the same meaning. Suppose you do this with the goal of leaving as few words in it as you can. In the end, you should have a small cluster of a bit over 100 words, in terms of which all the other words you removed can be indirectly defined.
(The idea of semantic primes also says that there is such a minimal set which translates essentially directly* between different natural languages.)
I don’t think that says that words for complicated ideas aren’t like, more complicated?
I wish they would keep 4.1 around for a bit longer. One of the downsides of the current reasoning based training regimens is a significant decrease in creativity. And chat trained AIs were already quite "meh" at creative writing to begin with. 4.1 was the last of its breed.
So we'll have to wait until "creativity" is solved.
Side note: I've been wondering lately about a way to bring creativity back to these thinking models. For creative writing tasks you could add the original, pretrained model as a tool call. So the thinking model could ask for its completions and/or query it and get back N variations. The pretrained model's completions will be much more creative and wild, though often incoherent (think back to the GPT-3 days). The thinking model can then review these and use them to synthesize a coherent, useful result. Essentially giving us the best of both worlds. All the benefits of a thinking model, while still giving it access to "contained" creativity.
My theory, based on what I would see with non-thinking models, is that as soon as you start detailing something too much (ie: not just "speak in the style of X" but more like "speak in the style of X with [a list of adjectives detailing the style of X]" they would loose creativity, would not fit the style very well anymore etc.
I don't know how things have evolved with new training techniques etc. but I suspected that overthinking their tasks by detailing too much what they have to do can lower quality in some models for creative tasks.
I also terribly regret the retirement of 4.1.
From my own personal usage, for code or normal tasks, I clearly noticed a huge gap in degraded performance between 4.1 and 5.1/5.2.
4.1 was the best so far. With straight to the point answers, and most of the time correct. Especially for code related questions.
5.1/5.2 on their side would a lot more easily hallucinate stupid responses or stupid code snippet totally not what was expected.
Have you tried the relatively recent Personalities feature? I wonder if that makes a difference.
(I have no idea. LLMs are infinite code monkeys on infinite typewriters for me, with occasional “how do I evolve this Pokémon’ utility. But worth a shot.)
Well yeah, because 5.2 is the default and there's no way to change the default. So every time you open up a new chat you either use 5.2 or go out of your way to select something else.
(I'm particularly annoyed by this UI choice because I always have to switch back to 5.1)
As far as I can tell 5.2 is the stronger model on paper, but it's been optimized to think less and do less web searches. I daily drive Thinking variants, not Auto or Instant, and usually want the _right_ answer even if it takes a minute. 5.1 does a very good job of defensively web searching, which avoids almost all of its hallucinations and keeps docs/APIs/UIs/etc up-to-date. 5.2 will instead often not think at all, even in Thinking mode. I've gotten several completely wrong, hallucinated answers since 5.2 came out, whereas maybe a handful from 5.1. (Even with me using 5.2 far less!)
The same seems to persist in Codex CLI, where again 5.2 doesn't spend as much time thinking so its solutions never come out as nicely as 5.1's.
That said, 5.1 is obviously slower for these reasons. I'm fine with that trade off. Others might have lighter workloads and thus benefit more from 5.2's speed.
reply