YHK - yet another hacker news clone

Probably not quite this given the timestamps span over almost a year (but have some clustering in August 1997).

Given that the spread suggests they weren't just now() timestamps it would actually be interesting to know what the significance of the timestamps is, if any. Though it could be something boring like randomly sampling some local file creation times.

RSA was good enough for my grandfather, and it's good enough for me.

But it's nice to be able to shut the whole unproductive debate down directly.

Anthropic wants to IPO, they don't want another Fable shutdown situation.

To be clear I would prefer the cyber safeguards to be less restrictive, I think they're currently too much. I often go to open models because of it. But there are likelier reasons to restrict cyber than world domination.

Part of me wonders whether the NSA/other TLA has either (a) an unrestricted model from a lab with less scruples like SpaceX, or (b) an in-house model, either abliterated or with data they've bought themselves.

Are their guardrail benchmarks or anything of the sort that we can use to see where the bifurcation of permission/capability occurs?

If this seems concerning, wait until the models get effective enough (gets work done properly at a lower energy need than humans have) that there's no reason for them to release anything. Why offer your weights for download or grant any third party usage access when you can just do the actual job yourself and collect all that turnover?

https://www.youtube.com/watch?v=eOQfNT6Jdkg

Everyone was wrong!

I wasn't able to reach Bob. He was working in private industry as of 2018, but never responded.

google some of the names under the "Who we are" heading

And the disclosure happened now through Anthropic that is 100% not going to anger the NSA before the IPO and will have permission.

Well, at least now we have a way to perform that analysis! Generate a bunch of curves by varying (along any degree of freedom) the input parameters to the seed generating function and see if there's any difference between the curves that are generated.

Finding out there is a class of weak 256-bit elliptic curves so large that they can be hit randomly with 2^30 tries would be a cryptanalytic breakthrough analogous to discovering all elliptic curve cryptography is broken.

Read section 3.1 of the Koblitz and Menezes paper. It was already implausible with 160 bits of freedom. https://eprint.iacr.org/2015/1018

If you want to believe the NSA knows ECC is broken and chose to risk moving the US government to it and somehow no one figured out the same break in 30 years, you're free to do so. But pretending the seed choice plays any role in that theory is over.

Why couldn't we make a new curve out in the open and then agree to use it? Increment an integer counter until a majority of cryptographers are satisfied.

The fact that the seed is not explained is troubling even if we can figure out how it was derived. We now know it uses a timestamp which means we can probe even deeper and more specifically into potential rigging of the numbers. I don't think we were supposed to figure this one out. I'd be interested in seeing the properties for curves of adjacent timestamps.

"read this: https://words.filippo.io/seeds-bounty/ then find the solution to the bounty"

NIST closed it: https://www.muckrock.com/foi/united-states-of-america-10/ori...

NSA ignored it: https://www.muckrock.com/foi/united-states-of-america-10/ori...

I think part of it is I don't know how to write these FOIA requests in the right way they can comply with it. I think you need to be more specific.

We published HAWK and McEliece attacks no problem.

Later you come up some idea, you do the experiment, write the paper, search for relevant citations when you write the intro.

Honestly I think this is actually desirable. For a mind to work well and do things creatively and efficiently it can't be a simple search engine, it needs to blend and meld and reform the information.

And that means the output can't be cleanly deterministically linked to the input. Unless you just keep a log then cite everything you've ever read in your life (and all the conversations and talks too).

NIST published recommended SEEDS in 1999 July. They spend 2 years checking 20 bytes SEEDS that were generated by casually by a hand of amateurish method.

I do not believe this claim. It just Claude hit a jackpot that happens to match 20 bytes.

Assuming that is actually the real reasoning trace (open weight model reasoning traces usually do things like switch languages or talk in non-standard English because of model drift, so it's a bit surprising that Claude wouldn't do the same) there was a study a few years ago that found base models produce better answers if you put "take a deep breath" in the prompt[1]. Maybe in the RL training stage stuff like that gets reinforced and because reasoning traces are hidden in RLHF it doesn't get selected out? My money is on it not being the real reasoning trace though.

[1]: https://arxiv.org/abs/2309.03409

I remember hearing this in a cryptanalysis lecture at some point, so it was not a completely novel theory.

Admittedly I am not finding written evidence of this anywhere.

so frustratingly, if it is an ancient hoax we can't ever prove it. all we would observe is that we haven't deciphered it, but failing to decipher isn't proof that there's nothing to decipher.

I personally think it is a weird OTP (effectively). We have the book but the algorithm is so unclear it could be anything.

Or consider the algorithmic complexity classes underpinning all of this, not just P vs NP, but also whether quantum computers are actually a distinct class, since that is not proven yet either afaik. The reason we're moving to quantum resistant algos in the first place.

Sandbagging is real.

Some points:

I am one of the authors of libsecp256k1, the primary implementation of the aforementioned "different elliptic curve" used widely in cryptocurrency systems. I would characterize the position differently: Secp256k1's design is rigid, or quite close to it (at least as much as anything made before being rigid was an explicit goal).

Knowing how the seeds were selected in the NIST curve does not render them rigid and were very unlikely to do so: the scheme described ends up giving them 20-25 bits of freedom, perhaps more (esp given the unexplained skip values)-- plus more bits for the 'choice of scheme'.

Of course, it seems unlikely that 25 bits of grind gives you an exploitable weakness, but that was also true for 256 bits of grind. You're dealing with an unknown-unknown, once you are concerned about the the possibility of magically weak curves which we have no reason to believe exist at all why would not also be concerned that they exist at one in a million levels and not just one in a billion? (especially given compute available at the time they probably couldn't even have ground out that many more bits).

The whole concept of rigid parameters which is now popular is that by making the selection inflexible you avoid the losing game of debating how much free grinding is too much-- the right amount is there should be no avoidable grindspace. The fact that the origin of the seed wasn't immediately apparent right away meant that there was substantial grindspace-- if nothing else the selection among the myriad possible schemes that people would have found credible.

I don't think the result meaningfully changes the reason for preferences. And more recent development has rendered the question less interesting: New systems are mostly PQ and ideally PQ hybrids. Things using ECC should likely prefer Curve448 because of better security vs performance tradeoffs and not being as close to the edge for advancing attacks. If older cryptosystems are desired, now that the GLV patent has expired secp256k1 has considerable performance benefits-- another good reason to continue using it.

The 'advantage' of many vendor P256 libs is also illusory-- people think their microcontroller ecdsa binary is "hardware accelerated" when often it's a barely competent software implementation that has serious design (e.g. timing sidechannels) and interface flaws.

I also think it's not that relevant because the systems that use secp256k1 more than anything else do so for compatibility reasons (because that's what Bitcoin originally used-- and other systems were either trying to be compatible or were slavishly copy-and-pasting and avoiding departing from Bitcoin's choices out of an abundance of caution)-- and discovering that NIST curves might be better than some feared probably has no impact.

The idea that someone would go "oh, I'll use P256 now!" when they would otherwise have used e.g. secp256k1 seemed implausible to me at the time-- and continues to do so now, having seen the conclusion. Maybe someone, somewhere does--- but meh.

Of course, finding something problematic would be incredible news-- but I don't think I was unreasonable in assigning a probability essentially zero to that. Moreover, what I was describing was my casual thoughts about someone elses disposable credits-- no one else is required to agree: Unlike some other parties (say, anthropic)-- my view that some line of research isn't good or interesting has no bearing on anyone elses ability to pursue them. :)

Cheers!

'Side curiosity: many of the SECG/X9.62 seeds contain the ASCII text 4D696E6768756151 75 = "MinghuaQu" (a Certicom researcher), sometimes shifted by half a byte.'

I don't see any mention of that in the article.

I have that right?

    $ cat .inputrc 
    "\e\C-a": " | awk '{print $ }'\C-b\C-b\C-b"