EnvKey[1] moved from OpenPGP (RSA) to NaCl[2] for its v2, which recently launched.<p>It’s causing a difficult migration for our v1 users. Moving to a new encryption scheme is <i>not fun</i> for a product with client-side end-to-end encryption.<p>But within a year or so of releasing the v1, it seemed like the writing was on the wall for OpenPGP and RSA. I didn't want to go down with a dying standard.<p>NaCl is <i>so much better</i>. In spite of the migration headaches that will likely cost us some users, I'm very happy I made this decision. It's so much faster, lighter, and more intuitive.<p>It’s legitimately fun to work with, which I never thought I’d say about an encryption library after cutting my teeth on OpenPGP.<p>1 - <a href="https://github.com/envkey/envkey" rel="nofollow">https://github.com/envkey/envkey</a><p>2 - <a href="https://nacl.cr.yp.to" rel="nofollow">https://nacl.cr.yp.to</a>
Sounds like the author would agree it's fine to use RSA, so long as you use an audited library with a well-designed API that makes it easy to do the right thing, and hard to do the wrong thing.<p>This makes me wonder, if we have an RSA library as good as libsodium, is ECC really a better choice than RSA?<p>I love libsodium and tend to choose it, but ECC seems far more mysterious to me than RSA. Curve25519 is much newer, has more parameters, and could potentially have a backdoor (like it's precursor, P-256). It also has much smaller, fixed-size keys.<p>RSA by comparison is elegant and simple to understand, with only one parameter. It's been in wide use since the 1970s. You can choose the key size.
This is all true, but reads funny to me because I've implemented an intentionally vulnerable version of RSA and still had issues getting timing attacks to work on modern hardware (due to lack of sophistication in my approach, I think).
RSA is bad, because developers do not implement it as specified and ECC is good, because most developers will not implement it themself, because they do not understand ECC and therefor use libraries? IMHO a huge advantage of RSA over ECC is it is easy to explain. After you have explained the different kinds of elliptic curves and their pitfalls, you have to explain the integrated encryption scheme to actually use it for encryption. But ok, you want hybrid encryption with RSA too, but in theory, you do not have to.
Here is a nice discussion of what happens when you don't validate your elliptic curve parameters properly:<p>* <a href="https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-elliptic-curve-cryptography-validation/" rel="nofollow">https://research.nccgroup.com/2021/11/18/an-illustrated-guid...</a><p>The highlight here is that in some cases, failure to properly validate gets an attacker the secret key material.<p>Note all the conditional bits. Different curves have different properties and different issues. There are a bunch of different curves in common use while RSA pretty much always uses the same value for the parameter these days (RSA literally has just one parameter. The exponent.).
“RSA is bad because developers often don’t implement it correctly, leading to vulnerabilities. Instead, use ECC, which can also be implemented incorrectly, but developers tend to do this less.”<p>The article raises some good points, but it really explains why you shouldn’t use your own RSA or an unaudited third-party library. A good RSA implementation which has been audited by security experts and doesn’t take shortcuts for performance would alleviate the OP’s concerns.
Past comments: <a href="https://news.ycombinator.com/item?id=20381779" rel="nofollow">https://news.ycombinator.com/item?id=20381779</a>
'"Seriously, Stop Using RSA" for Dummies' please!<p>e.g. for a fullstacker who spins up the latest Ubuntu LTS then generates a pair of 4,096-bit RSA keys using default openssh-server set over a high-number TCP port, what should they be doing that is different?
Just to say, understanding the complexity of the topic they are discussing, this is one of the finest pieces of writing I have ever read. If you can express this issue clearly, you can express anything clearly, imo.
Isn't RSA the best assymmetric crypto system for when you do need that? I mean, I get it for signatures, key exchange and data encryption it should be avoided but what else is there for symmetric key encryption such as how S/MIME uses it for example. I always thought RSA+OAEP with >= 4096 bits was an acceptable way to encrypt symmetric key material for transport.<p>I only know of PGP as the alternative which isn't well supported in many environments (especially commercial).
Article is from 2016. It is a good article, but why does it say OAEP is notoriously difficult to implement? OAEP seemed very natural to me, and I "invented" it myself (long after it was well known to others, of course), i.e. the ideas in it weren't complicated. Am I missing something dumb?<p>I do remember hearing that Victor Shoup found some kind of bug in the security proof, but it wasn't something of practical concern.
I have a vague understanding that it is not so easy to encrypt data with ECC as it is with RSA. Is that true? This is one reason I still use RSA. What is the right way to use an ECC public key to encrypt data so only the holder of the private key can decrypt it? (Without any fancy key exchange - just fire and forget, email style)
meh. dude seems to be conflating "don't use RSA" with "don't roll your own crypto."<p>If we are to believe Scott Vanstone, ECC has security proofs that RSA doesn't. And I found Scott was a pretty trustworthy guy.<p>So the OP has a point. It's probably easier to mess up RSA then ECC. But it's not easy to not mess up ECC, so maybe the title should have been "for the love of god, don't roll your own crypto."<p>Maybe look at NTRU. It's supposedly quantum resistant, so that's a plus. But for the love of god maybe don't roll your own.<p>I contributed to two and a half commercial implementations of RSA and I still got Bob Baldwin to review my code. Bob was hip-deep in crypto research and knew how to avoid even obscure bugs.<p>I miss Scott and Bob.<p>Also... I'm using the term "Crypto" to mean "Cryptography" and not a solution in search of a problem crypto-currency.<p>Still. Don't roll yer own crypto.
There is a menu of ECC algorithms out there. We have seen some of them were backdoored, and there are probably more of those.<p>If you aren’t sure which ones are safe, it might be better to use RSA from a standard source (OpenSSL, PGP, SSH etc).<p>Users don’t implement algorithms, and don’t cares if they are hard to program.
Is there any new concern that Curve25519 has been backdoored by the NSA? It looks like P-256 did a long time ago, and reading the Wikipedia article doesn't give that impression, wanted to check though.
There's an extremely interesting rebuttal that appears as a comment in the original article. I'm going to quote it below for the benefit of HN readers.<p>/QUOTE<p>Bob, February 28, 2020 at 12:15<p>KEEP USING RSA!<p>This article is misleading to make it appear that RSA is not secure, but only the only evidence presented is improper implementation.<p>Properly implemented RSA has been proven secure and unbreakable by the NSA with case studies such as Snowden, Lavabit, dark markets, and ECC is much harder to properly implement than RSA.<p>The NSA has been pushing ECC because their quantum chips can break it easily. D-Wave, Google, Alibaba, and others already have quantum chips. The disinformation agents claim that “quantum computers don’t exist” which is true because nobody uses a computer to break crypto, they use specialized custom chips.<p>All ECC (X25519-P521) will be broken by private sector quantum chips before RSA-2048 due to the physical limitations of stabilizing qubits.<p>The people making false claims against RSA are either being paid or they are useful idiots.<p>/END-QUOTE
1) Post needs a "2019".
2) Best comment inside was from Philip Zimmermann: "I agree. This is why I switched to El Gamal as the default algorithm for PGP version 5 in the late 1990s."