Been diving into the whole NSA tampering thing with crypto standards. Seems like a scare tactic to make us doubt the math itself instead of just the providers. Makes me think this is more about their direct attacks than anything else.
Concerns About NSA Influence on ECC Standards
21 replies 103 views
Yeah, I'm with you on that. But what bugs me are those constants in the SEC curves. They claim to be random but are they really? Nobody seems to know how they could be exploited if they aren't truly random. Makes you wonder.
Exactly. But at least Bitcoin sticks with a Koblitz curve that has solid reasoning behind its constants. The NSA isn’t actively after Bitcoin anyway; they’re more about surveillance than financial systems.
atlas_minerNewbie
Posts: 110 · Reputation: 19
#4Apr 11, 2024, 06:57 PM
So you’re echoing that guy from Schneier's blog, huh? He mentioned backdoors in recommended random generators for ECC and weaknesses in certain curves. But since we use secp256k1, it might not be a big deal for Bitcoin.
Right? The whole random selection thing for those curves makes it harder to mess with. I do think about the DLP solving techniques, though. If someone cracks those for regular curves, we might be in trouble.
Schneier’s point is interesting since we can’t know the full extent of NSA's cryptanalysis skills. If there’s a weakness, it’s likely curve-specific. But random or not, Koblitz curves like ours were also picked randomly, so... how can we trust any of this?
LuckyOrbitNewbie
Posts: 8 · Reputation: 18
#7Apr 14, 2024, 03:33 AM
That’s what’s really got me thinking. We should dig into how secp256k1 was created and what went into its approval. I get that Bitcoin can switch signing methods if flaws are found, but still, curious minds wanna know.
atlas_minerNewbie
Posts: 110 · Reputation: 19
#8Apr 14, 2024, 07:07 AM
Saw a piece from John Gilmore on the NSA’s obstruction tactics. They've been messing with standardized security systems for years. It wouldn’t surprise me if they also tried to sneak in some dodgy random constants.
I think you’re mixed up there. Koblitz curves are different from those random ones everyone else uses. Most EC stuff online is using prime random curves, like P-256r, which have their selection process published.
atlas_minerNewbie
Posts: 110 · Reputation: 19
#10Apr 14, 2024, 09:45 AM
The talk about 'good guys' doing bad stuff is wild. We seem to be hitting a point where we know certain actions are wrong. So, can anyone really be a good guy if they’re doing harmful things with intention?
Started looking into the seeds for secp256k1, and wow, the P-NNNr ones have some sketchy seeds. Like, how do they know those values are even remotely safe? Feels like a gamble.
atlas_minerNewbie
Posts: 110 · Reputation: 19
#12Apr 14, 2024, 09:45 PM
You’re right about Bitcoin’s curve. It was set up by Certicom, which is connected to RIM, the Blackberry folks. They’ve been under scrutiny for possible NSA ties. Makes you think, right?
Actually, Certicom is Canadian. The magic numbers in secp256k1 are pretty tight due to the curve’s special form. But who knows, it could still be weak in the long run.
I still defer to gmaxwell on this. I drive by Certicom's office regularly but didn't realize they were a Canadian company. Guess I was wrong about that.
Someone should really go through Certicom’s meeting minutes to see how they picked those parameters. There might be some clues in there.
This brings me back to our chat about brute-forcing wallet.dat files. Is the time it takes linked to those magic numbers?
atlas_minerNewbie
Posts: 110 · Reputation: 19
#17Apr 15, 2024, 01:20 PM
Wallet.dat uses AES for encryption, not that complicated symmetric stuff. We designed it deliberately to slow down brute-forcing. ECDSA signatures need to be quick though since all nodes validate transactions.
Thinking about ECDSA, what if we added another signature method that doesn’t need a nonce? Once most nodes switch, we could phase out the old method.
stack_nodeNewbie
Posts: 1 · Reputation: 11
#19Apr 15, 2024, 07:04 PM
Good point, but using a nonce helped us catch that Android RNG issue. Shifting away from it could hide future problems we wouldn't even see coming.
gmaxwell suggested BIP 0032.5 for deterministic ECDSA signing. It’s compatible with existing verification, so any Bitcoin client could adopt it easily. Seems smart, right?
Related topics
- Curious About Bitcoin Tech? Need Resources 8
- Issues with ripemd160 on Ubuntu 22 9
- New Bitcoin Improvement Proposal with $100 Reward 9
- Clipboard Vulnerabilities in Cryptocurrency Transactions 8
- Understanding the Differences Between Traditional and Simplified Chinese Mnemonics 6
- Running Bitcoin Core on a Laptop with Limited Storage 20