Seriously, Stop Using RSA (2019)
51–60 of 125 posts
Re: Seriously, Stop Using RSA (2019)
#52Sounds 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. This makes me wonder, if we have an RSA library as good as libsodium, is ECC really a better choice than RSA? I love libsodium and tend to choose it, but ECC seems far more mysterious to me than RSA. Curve25519 is much newer,…
RSA has been in use since the 1970s and has been repeatedly shown to be extremely easy to introduce seemingly minor issue that completely break the crypto.
Among the many issues are the belief that encryption is just P^^message%N. Which it is not - you must include padding, and doing that padding wrong also breaks the security.
In general implementing RSA safely is very hard, then you also get to the the huge keysizes required for acceptable levels of security.
An encryption scheme seeming elegant or understandable is not a sign of strength. Neither is age, as basic ciphers like Am+B%N have been used for thousands of years, but are trivially breakable.
Furthermore, while RSA dates to the 70s, ECC still dates back to the early 80s IIRC.
As for RSA being easy to understand, I’m not sure why you think ECC is hard to understand - you follow the specified addition operation and you get the correct result. I would argue it’s even easier to intuitively understand than RSA, as the whole point is that you’re both adding secret numbers together in such a way that you end up with the same total. This is unless you find the Chinese remainder theorem obvious?
Honestly my current preferred encryption scheme is McEliece. Basically you generate an error correction code for a message such that it can correct half the bits in the message. The public key is your error correcting codes basis matrix multiplied by a permutation matrix to shuffle the bits around. Encryption is done by multiply the public key matrix by the message and then flipping half the bits. Decryption is simply inverting the permutation and performing the error correction.
As a bonus, in addition to being simple McEliece has also been around since the 70s, encryption and decryption is extremely fast, it has withstood huge amounts of research and isn’t broken by quantum computers. On the downside the keys are impractically large :(
Re: Seriously, Stop Using RSA (2019)
#53Earlier quoted context omitted.
Oh. I thought it was because there are at least a dozen ways to securely encrypt/decrypt data, most of which are audited. Skimming their site they seem to offer some sort of encryption + service hosting? I don't see how this is much different than any of the other options out there. And not really an equivalent to using RSA as it looks to be tied to their hosting. I also tend to not trust for profit companies with th…
> I thought it was because there are at least a dozen ways to securely encrypt/decrypt data, most of which are audited. Any yet people still implement on top of and leverage those lower-level libraries poorly. >Skimming their site they seem to offer some sort of encryption + service hosting? I believe they have a hosted SaaS solution now, but Vault is FOSS: https://github.com/hashicorp/vault >I don't see how this is…
Re: Seriously, Stop Using RSA (2019)
#54Sounds 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. This makes me wonder, if we have an RSA library as good as libsodium, is ECC really a better choice than RSA? I love libsodium and tend to choose it, but ECC seems far more mysterious to me than RSA. Curve25519 is much newer,…
> This makes me wonder, if we have an RSA library as good as libsodium, is ECC really a better choice than RSA? Yes, absolutely. Compare the key generation process, for example: RSA: generate two large prime numbers around half the size of your key, then make sure they aren't too close to each other, or share one of the primes with another RSA key someone else generated, or have certain mathematical relations to each…
What bits?
Re: Seriously, Stop Using RSA (2019)
#55Earlier quoted context omitted.
> This makes me wonder, if we have an RSA library as good as libsodium, is ECC really a better choice than RSA? Yes, absolutely. Compare the key generation process, for example: RSA: generate two large prime numbers around half the size of your key, then make sure they aren't too close to each other, or share one of the primes with another RSA key someone else generated, or have certain mathematical relations to each…
>set and clear a couple bits What bits?
https://neilmadden.blog/2020/05/28/whats-the-curve25519-clam...
Re: Seriously, Stop Using RSA (2019)
#56Earlier quoted context omitted.
The article discusses this, the difference is that ECC parameters can be chosen before library-development time by expert cryptographers, all the developers have to do when actually developing the library is to generate random bits. The obviously complex mathematics of EC intimidate the non-experts away from trying to roll their own implementation and push them towards the most trusted expert implementation, while th…
p and q are not parameters, they're the secret key. A "parameter" in this sense is a constant that defines the behavior of the algorithm that all users of the algorithm must agree on, otherwise they can't communicate.
Re: Seriously, Stop Using RSA (2019)
#57Sounds 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. This makes me wonder, if we have an RSA library as good as libsodium, is ECC really a better choice than RSA? I love libsodium and tend to choose it, but ECC seems far more mysterious to me than RSA. Curve25519 is much newer,…
> This makes me wonder, if we have an RSA library as good as libsodium, is ECC really a better choice than RSA? Yes, absolutely. Compare the key generation process, for example: RSA: generate two large prime numbers around half the size of your key, then make sure they aren't too close to each other, or share one of the primes with another RSA key someone else generated, or have certain mathematical relations to each…
Re: Seriously, Stop Using RSA (2019)
#58Earlier quoted context omitted.
>set and clear a couple bits What bits?
Clear the highest bit, set the next highest bit, and clear the three lowest bits. This process is known as "key clamping", and ensures that the private key is in the right range and is not vulnerable to a couple of specific attacks. https://neilmadden.blog/2020/05/28/whats-the-curve25519-clam...
Re: Seriously, Stop Using RSA (2019)
#59Earlier quoted context omitted.
Quoted post unavailable.
>From what I can tell, Vault doesn't handle generating SSH keys in the first place Nor should it. That's managed by ssh-keygen. Hello UNIX philosophy! >so reading the docs or finding an expert on the allegedly easiest security tech wouldn't be of much help. If you're not an expert or feel confident in secops, find someone who is. Security is obviously something that shouldn't be taken lightly.
Re: Seriously, Stop Using RSA (2019)
#60Earlier quoted context omitted.
Clear the highest bit, set the next highest bit, and clear the three lowest bits. This process is known as "key clamping", and ensures that the private key is in the right range and is not vulnerable to a couple of specific attacks. https://neilmadden.blog/2020/05/28/whats-the-curve25519-clam...
Starting to sound a lot like your description of RSA, just more positive about it.