Hacker News new | past | comments | ask | show | jobs | submit login

My takeaway from this article is that the problems are indeed implementation-specific, but that whilst the cryptographically-secure values represent a small subset of the possible values, it's still too large a selection to provide a generalised list of what values are suitable for purposes. They do admit that RSA can be implemented securely in theory, but that the range of possible implementations is so vast that it's incredibly difficult to know if the parameters chosen are vulnerable without a maths degree and some very deep analysis.

On the other hand, those of us who write code that uses crypto are generally beaten about the head with 'NEVER ROLL YOUR OWN CRYPTO' and use library implementations right from the start. These are libraries that I assume are indeed written by people with maths degrees and have done careful analysis of the outputs. I know for a fact that I wouldn't trust any encryption I could write myself in an hour.

The biggest obstacle I find with ECC is that it's relatively easy to judge security by RSA (assuming correct implementation) but it's surprisingly difficult to compare the two; if I want RSA-2048, what key size am I supposed to use. ECC was also heavily promoted as offering 'RSA-equivalent security' while using less CPU, which made it particularly suitable for mobile/embedded systems, without necessarily implying it was an improvement over RSA.






> I know for a fact that I wouldn't trust any encryption I could write myself in an hour.

That's what I would trust the most. Not that such a thing actually exists (Chacha20 is one of the closest), but if I can implement it quickly in an hour, and it is vetted by the community, then peer reviewed implementation like Libsodium are much more likely to be correct.

> The biggest obstacle I find with ECC is that it's relatively easy to judge security by RSA (assuming correct implementation) but it's surprisingly difficult to compare the two;

Then don't. Compare them with hashes instead. Oversimplifying things a bit, breaking a curve of a given size is about as hard as finding a collision of a hash of a similar size. So, Curve25519, which uses about 255 bits, is about as secure as Blake2b/256, or HMAC-SHA256. That is, about 128 bits of security.

Note however that this is more secure (without quantum crypto) than 128-bit ciphers like AES-128, because hash collisions and elliptic curves aren't as vulnerable to multi key attacks, and success rates drop faster when you try to be lucky with less computational resources than you should have used.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: