Openai to Anthropic history:
house of Samuel is Openai,
Samuel is Sam Altman,
Darius is Darío Amodei,
And Adam is Anthropic, with a biblical narrative...
It wasn’t. The person that posted the factorization has nothing to do with Anthropic, and has for many years held the leaderboard on GPU-hours applied to factorization and prime search problems. He’s not yet on record as to how this one was done (probably waiting for publication), but there is no reason at all to assume any LLM was involved.
Because there is nothing not already automated here. RSA will either be cracked because some assumption about prime numbers doesn’t hold or because we throw more and more brute force on it.
And if it were the former it wouldn’t be the “next” in line that would be cracked…
You don't have to have RSA be broken in order to get a competitive advantage over other people searching. You just need Claud to find software optimization that got overlooked or something from number theory to come up with better candidates to guess.
No, the funny thing is that this comment is comming from an account with 1 karma, no submisions and only 1 comment, I wonder if this is your only account and you just came to spill hate or you are using multiple accounts to discredit other peoples work.
Two months and 1.1k+ commits to rediscover an already known bug IS funny. That doesn't mean I hate the person or want to discredit their work. You're reading way too much into a comment :)
Humor is subjective, not objective; if we delve into the subjective realm, I can feel whatever I want, just like you. You haven't offered anything constructive yet. I'm more willing to listen to your ideas if you have any.
I really wasn't trying to offer anything constructive. I was just pointing out something I found funny and made a joke about it. It wasn't anything more serious than that.
Yeah that was my bet, escaping the local minima imposed by the current state of fuzzing. I am seeing this problem as statistical and information theory problem.
Some day someone by chance will create another fuzzer that would find more bugs because of the blindspots in the previous generation including mine.
OP here: for those interested is not that an LLM found the bugs the fuzzer found them.
My take on this matter was to implement as much information theory algorithms as possible, and try to extract as much structure with statistical importance from the binary being fuzzed. Also port as much features from other fuzzers and whie papers on the mater (llms are good at connecting dots across vast codebases and papers).
I honestly can not take full credit for this work since I made it with AI, but I has taken two months of my time and 1100+ commits.
My developing process was to use several models from several vendors not just Claude that decouples it from a single vendor/model and throws to the flor that llms regurgitate verbatim code.
Also the interesting part is the developing pipeline I have had setup my own cicd with my own tool impactguard whitch saved me a couple of times and hard rules on the agent.md(70% to 80% of those rules i wrote them by hand).
The pytest testing battery is also interesting, I adopted TDD and to me since I adopted it seems that llms make less bugs.
Yes I know the code and the readme might look like ai slop as pointed out earlier but is efective at finding bugs. At the end of the day is all economy: you spend a lot of tokens once and keep the fuzzer forever, not the same as paying every time for tokens to find bugs.
As pointed out in the readme, this fuzzer trades speed for edge novelty, maybe there is it's niche.
Also we found earlier another bug with this fuzzer https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/23945.
For the concerned IMO: rather than the results the methodology is more important.
I welcome constructive criticism and feedback. Any input is useful to me.
I can't speak to the quality of the fuzzer since I haven't used it or looked at it thoroughly, but it does seem to cover a lot of ground on features and interesting concepts. I'll definitely be reading more into what you have here.
OP here: A bug report just needs a proof of existence for the condition while a bug fix needs a proof of correctness. Sometimes is the best to let the developers who are day to day in the codebase to choose the best fix and if they what to fix it.
If one were to go about translating brain waves from dogs to meaning, we'd run into a big problem immediately: vocabulary resolution.
What I mean by that is we'll have a very limited number of words to which a dog's brainwaves can be translated to since we aren't able to understand them beyond their basic instincts of food, survival, fear, affection towards their owner etc.
There is just no way to go past what we have already observed by their behavior since dogs can't talk or write.
I do wonder how animals think. Perhaps this resolution would also be the theoretical maximum?
>There is just no way to go past what we have already observed by their behavior since dogs can't talk or write.
There are many dogs that have been trained to press buttons corresponding to words, in the extreme case tens/hundreds of buttons/words, and they can even construct rudimentary sentences. It doesn't seem insane to me that we could perhaps do a very rudimentary version of this for dogs, given a large enough training set.
The "vocabulary resolution being low" basically just means within our own limited context, it's low. But that doesn't mean it's a good measure. Heck, I'd say it isn't.
reply