Does that encryption requirement make sense?

Has anyone ever told you that you should use at least RSA-4096 to encrypt data? Don’t believe them!

I’ve seen this requirement on multiple occasions. But what’s the problem with it? Let’s break this up in parts.

• There is a requirement to encrypt data. This is a good thing.
• You should use an algorithm that is adequate to protect the data.
• For that, the minimum is using RSA, with a minimum key length of 4096 bits.

The problem is the last sentence. And it's two-fold. One, it says you should use RSA to encrypt data, and two, it can lead you to think that there is a separate requirement that the key length for any encryption algorithm (not just RSA) is 4096 bits.

RSA is a so-called ‘public key encryption’ algorithm. This is almost a bit of magic. It allows to you encrypt some data in a way that only the intended recipient can decrypt it. But unlike conventional encryption algorithms like AES or ChaCha20, the sender and the recipient don’t share the same key for encrypting and decrypting. In fact, the recipient can give the encryption key away to anyone – it’s a public key. They just need to keep the decryption key secret.

You can see how this is useful; public key encryption allows your bank to have a website that anyone can access, and the data is securely encrypted.

But using a public key to encrypt data is actually not what websites are doing (see below). Pretty much no-one is using RSA (by itself) to encrypt data. Most notably, any trustworthy encryption software won’t do that. And when it comes to encryption, you don’t want to “roll your own”.

The requirement should more properly be,

Use a secure encryption algorithm (like AES-GCM or ChaCha20), and if it’s the case that the encryption and decryption are being done by different parties, use certificates.

Bigger isn't always better

The implication that the key length should be more than 4096 is also problematic.

For encryption, algorithms like AES-GCM and ChaCha20 only need 256 bits of key length to be secure. The public key magic being done by RSA is much weaker, which is why it needs so many bits to be secure. Other public key algorithms, like elliptic curves, use naming/numbering schemes that don’t have much to do with key lengths, like Curve25519.

Our revised requirement (use a secure algorithm) suffers from a fatal flaw. How do I know that Curve25519 is adequate? What about Kyber768? Is it less good (after all, the number is lower)?

How to know you're doing the right thing

A requirement like this would need continuous updating. But there’s help! Your national cyber security center provides guidelines. The current guidelines from NCSC.nl recommend using AES-256-GCM, ChaCha20-Poly1305 and AES-128-GCM. That last one will probably be gone in the next version. And it will likely include post-quantum encryption as an additional layer of defense, like in the X25519Kyber768 combination being trialed (in production!) by Cloudflare and Google’s Chrome.

How do you check if you’re up-to-date? Well, for a public website, head over to https://ssllabs.com/ssltest/ and see if you score an A or better.

“Public websites should score at least an A on SSL labs” is a requirement that is much better than the original. But it doesn’t cover “encryption at rest”. The good news is that you probably don’t need any of that public key business for encryption at rest. The less-magic algorithms like AES are not affected by the quantum cryptography research where a lot of things are happening, and AES-GCM with 256 bit keys will keep your secrets safe for a long time to come.

This week’s takeaway is: don’t roll your own encryption requirements! Use the recommendations of your national cyber security center.

Also, except for just checking file integrity, stop using MD5 and SHA-1, upgrade to SHA-256/512.

What happens when you connect to your bank’s website?

For a HTTP connection, the data is not being encrypted with public key encryption like RSA. It’s actually being encrypted with AES or ChaCha20. Those algorithms are not as magic. They need a shared key, and a key exchange algorithm like Diffie-Helman is used for that.

To make sure that this shared key is not tampered with (by a ‘man in the middle’) digital signatures are used. A check is performed that you and the bank are using the same key, by using a digital signature.

Public key encryption is actually being used for key exchange and digital signatures. Not for encryption.

Since you’ve never met the bank, you need to verify their digital signature by checking their ‘certificate’. That certificate will be signed by a company that does nothing but checking that website owners actually operate the website you’re visiting (sometimes, they will even check their corporate papers). But those companies themselves may need a certificate to authenticate their key, which can form a chain up to a ‘root’ certificate installed by the company that made your browser. This is called the certificate chain.

So in the end, Mozilla, Microsoft, Apple and Google determine whether your bank’s certificate is trusted! This is what is meant when people refer to ‘Public Key Infrastructure’. Just a public key won't save you, you need a away to get the right one to the public, without it being substituted with an attackers'.