Just came across this challenge and thought some of you might find it interesting. Apparently, there's a bounty for anyone who can crack the seeds behind the NIST elliptic curves. Check it out here.
I've been looking into it already. For instance, I started using Sage to calculate n-values based on p-values and diving into point counting algorithms. Still a work in progress for creating my own implementation. But with certain revealed seeds like 'MinghuaQu', I feel like there was no hashing involved, just basic operations to get the numbers.
Yeah, but the real issue is we don't know the algorithm. I can toss out a random hint, but who knows if it's useful? People have been speculating it's just SHA-1 on something like 'Hello, world!', which seems plausible.
This doubling of the mystery point with a small x is not a big deal for me. Many curves were generated in a somewhat random way using SHA-1 output. It’s common to multiply a candidate point by the curve's cofactor to eliminate subgroups. I think someone just reused code that wasn’t necessary for secp256k1.
That makes sense. I suspect the 'random curve' issue might link to secp256k1 G question too. If the procedures are similar, they should have some similarities in seeds. But the incrementing method seems off, since the G values across different curves share too many bits.
Exactly. They likely incremented the hash but didn’t rehash the data. I’m guessing the value after hashing is around '0554123b78ce563f89a0ed9414f5aa28ad0d96d6795f9c66'. It might be mixed and cut in some way, but I’m not sure about the final q-value.
Yeah, I warned you about relying on AI. You shared a loop that runs 20 million times for no reason. That's 2.5 million times slower than it should be. Plus, don’t forget, there are only a few thousand hashes, so brute forcing anything larger than 16 bits is probably a waste.
ChatGPT with GPT-4 has a math plugin that can connect to Wolfram | Alpha, but I doubt it can handle cryptographic stuff like SHA-1. I’ve never used it since it’s a paid feature, and I don’t want to cough up 20 bucks a month just for that.
I stumbled upon a bunch of seeds (around 13) but can’t spot a clear pattern. I might compile all seeds from the SEC2 document into one list. It’s curious how the transition from sect131r1 to sect131r2 seems like a call to a 'seed transformation function'.
Why on earth would someone use such a simple phrase to generate seeds for standardized elliptic curves? Given the issues with brainwallets, isn’t that risky? Using truly random bytes would be way safer.
1. There were 'nothing-up-my-sleeve' numbers used to make curves. 2. Some FUD claimed those curves were insecure for being 'not random enough'. 3. New random curves were created to counter that FUD. 4. This led to more questioning about randomness, causing additional FUD.
I whipped up a quick CUDA program for SHA-1 mining, hitting around 5 Giga hashes per second on an RTX3090. The hard part is generating the password candidates, which might be slower than hashing.
I think someone just started with 'srand(time(NULL))' for seed generation. That could happen in production code. We might need to look into old srand implementations to understand this better.
There are more MinghuaQu seeds, but I’m curious about their exact patterns. If we could figure out how to jump from one seed to another using 'MinghuaQu' concatenated with some bytes, that would be a breakthrough.
For Bitcoin’s value, I suspect it ties back to secp192k1 due to its digit count and the presence of a certain point on all y^2=x^3+3 curves. The generator might just be that point multiplied by a 160-bit SHA-1 value.
I'm wondering what the c-value is for curves like secp160k1 and secp256k1. If we look at the generation procedure, we can calculate c based on b values.
Could the low y-value be derived from the x-value? When I tried changing the b-value for secp192k1, it didn’t work as expected. But it worked for secp160k1 and secp256k1.