Hacker News Reader

Comment by spuz | Hacker News Reader

I'm definitely missing something here. The standard size of both Ethereum and Bitcoin private keys is a 256bit secp256k1 key. If a 256bit key is guessable within 20 mins then the entire Blockchain is also broken.

View on HN

The article doesn't mention this, but if you look at the paper[1] it turns out they aren't using ElGamal with elliptic curve fields -- instead they're using prime fields. In that case, you'd want similar key sizes to RSA. (The "less than 256 bit" part is a red herring, the problem is that they are using key sizes that would only be safe if they were using elliptic curves.)

[1]: https://arxiv.org/pdf/1908.05127.pdf

Wow, they are using conventional discrete log cryptography with 256-bit key? What the actual fxxk?! It's literally the equivalent of using 256-bit Diffie-Hellman, or RSA-256, DSA-256, dammit, even NSA's bad DH_EXPORT ciphers use 512-bit. Totally unbelievable.

Wow. Even I know this. It's mentioned in every entry level text on EC cryptography.

Haha same. You know it's bad when someone with only an introductory course in cryptography understands what the problem is

Totally different kind of cryptography. sec256k1 is an elliptic curve, and 256-bit elliptic curves are generally believed to provide comparable security to 3072-bit RSA or DH or ElGamal. (See https://www.keylength.com for a good compilation of reputable comparisons along these lines.)

When I click the reference footnote on that page leading to iad.gov I get an invalid certificate authority error, heh.

https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for...)

For obvious reasons, the US government was never an authorized CA in firefox, and the application to be put on the list of trusted CAs was denied. The DoD root cert (for .mil addresses) is similarly distrusted. AFAIK most other browsers operate similarly. If you so desire, you can simply add the FCPCA and DoD certs to your trust store. Or... you know.. not.

https://wiki.mozilla.org/CA:GovernmentCAs

https://bugzilla.mozilla.org/show_bug.cgi?id=478418 (Status: RESOLVED WONTFIX)

https://fpki.idmanagement.gov/crls/

https://www.dau.edu/faq/p/DoD-PKI-Certificates

Although it kinda makes you wonder why China's CA was trusted by default, and it took actual, in-the-wild fraudulent certs before it was revoked.

My understanding is that the FPKI has tons of sub-CAs all doing their own thing and thus couldn't meet the Baseline Requirements. If they could meet the BRs then I'm sure the public comments would be full of comments about the NSA et al, but pre-CNNIC Mozilla was a lot more willing to follow a technical checklist for approval. The the recent DarkMatter request indicates the process isn't so trusting anymore.

Shame you can't add CAs for a particular set of subdomains, that it's all or nothing.

Yeah it really doesn't make any sense that it's not that way. I'd very much like to add the fcpca cert for .gov addresses and dod cert for .mil addresses, as I sometimes use these TLDs for work, but it doesn't make any sense to enable them globally. In fact I would like to ban all other CAs from those TLDs as they would be obviously fraudulent. I wouldn't have an issue adding cnnic for .cn either.

While I'm at it, why can't... Nevermind. The certificate authority system is so damned broken I could sit here for hours. Arrrg.

Scanned the paper and looks like they're using keys that are < 256-bit hence the vulnerability. Also I think the encryption keys which were found vulnerable are separate from the transaction signing keys

But then the article and its citation is plain wrong. 256 bit keys(3 of them) are cited multiple times

""This is a mystery," the French researcher said. "The only possible explanation we can think of is that the designers thought this would compensate for the too small key sizes of the primes involved. But 3 primes of 256 bits are really not the same as one prime of 768 bits."

However, a public key of a length of 1024 bits may not be enough, according to Gaudry, who believes officials should use one of at least 2048 bits instead."

The paper[1] makes it much clearer. They aren't using elliptic curves, they're using prime fields with ElGamal (with a weird construction using three separate keys for some reason). The security is similar to RSA-256 (in other words, "awful") -- it makes sense that they could crack it in 20 minutes.

[1]: https://arxiv.org/pdf/1908.05127.pdf

Why do people do weird stuff like this when there is gobs of good ECC code for things like ed25519 and ECDSA with standard curves that is easy to use and just sitting on GitHub?

Implementating complex crypto correctly is hard but its really not that tough to use common constructions in a secure way. A few days of reading can tell you how to build a cryptosystem that is at least not total holey cheese.

One theory that the paper has (in the last page) is that the reason for the construction was a consequence of Solidity only having support for 256 bit integer arithmetic. So as a workaround (to avoid writing a library that does larger bit operations) they came up with a scheme using three 256-bit keys instead.

Obviously using Curve25519 would've made it possible to have a secure setup under the "256 bit arithmetic only" constraints, but I have a feeling (assuming this theory is correct) that someone who thinks that three 256-bit keys are significantly more secure than one 256-bit key probably would've messed that up too.

Reply on news.ycombinator.com