AES vs RSA Encryption: Why We Encrypt Notes With AES-256-GCM

Every service that encrypts something has to choose between these two families, and the choice is usually made silently. This article explains the difference between AES vs RSA encryption and then does something most explainers do not: it states which one we picked for Inkrypt's note content, what the alternative would have cost, and why the answer is not close.

Understanding the difference is critical when securing sensitive data on the internet. While both algorithms protect information, they operate using entirely different mathematical principles. AES uses symmetric encryption, meaning it relies on a single shared secret key. In contrast, RSA uses asymmetric encryption, which relies on a mathematical pair of encryption keys (a public key and a private key). Knowing when to use each—and why they are almost always used together—is the foundation of modern digital privacy.

Symmetric vs Asymmetric Encryption: The Core Difference

To understand how these algorithms work, you must understand how they handle cryptographic keys.

• AES (Advanced Encryption Standard): This is a symmetric encryption algorithm. Symmetric encryption uses the exact same secret key to both encrypt the plaintext and decrypt the ciphertext. Because the same key is used on both ends, it must remain absolutely secret. If an attacker discovers the key, they can read the data.
• RSA (Rivest-Shamir-Adleman): This is an asymmetric public-key cryptosystem. Asymmetric encryption uses two mathematically linked keys. One key (the public key) is shared openly with the world and is used to encrypt data. The second key (the private key) is kept strictly secret by the owner and is used to decrypt the data. What the public key locks, only the private key can unlock.

AES vs RSA Encryption: Key Differences

While both secure data, they are tools built for very different jobs.

When to Use AES

Because AES is highly efficient and operates quickly on modern processors, it is the standard choice whenever you need to protect large amounts of data. You should use AES for:

• encrypted notes
• files and documents
• hard drive backups
• databases
• chat messages
• large data transfers

When implementing AES, modern systems typically use AES-GCM (Galois/Counter Mode). AES-GCM provides authenticated encryption. This means it not only scrambles the data to ensure confidentiality, but it also creates an authentication tag to guarantee the data has not been tampered with. To remain secure, AES-GCM strictly requires a unique, never-repeated nonce (or IV, initialization vector) for every single encryption operation performed under the same key.

When to Use RSA

Because RSA involves complex mathematics (factoring large prime numbers), it is computationally heavy. Therefore, it is rarely used to encrypt actual data payloads. Instead, you should use RSA for:

• encrypting or wrapping symmetric keys
• digital signatures to prove authenticity
• identity verification
• public-key encryption over open networks
• legacy or specific protocol configurations (like older TLS handshakes)

RSA should generally not be used to encrypt large files or long messages directly. Because the data being encrypted must be smaller than the RSA key itself, attempting to encrypt a video or a long document with RSA directly is both impractical and inefficient.

Why Modern Systems Use AES and RSA Together

Because AES is fast but struggles with secure key distribution, and RSA is great at secure key distribution but too slow for large files, modern systems combine them. This is called hybrid encryption.

Here is a step-by-step example of how hybrid encryption works when Alice wants to send a secure file to Bob:

1. Generate a random AES key. (Alice's computer creates a fast, unique symmetric key).

2. Encrypt the content with AES. (Alice encrypts the large file using the AES key).

3. Encrypt or protect the AES key using the recipient’s public key. (Alice uses Bob's public RSA key to lock the small AES key).

4. The recipient uses the private key to recover the AES key. (Bob receives the package and uses his private RSA key to unlock the AES key).

5. The recipient decrypts the content. (Bob uses the unlocked AES key to decrypt the large file).

Note: While RSA pioneered this model, modern TLS commonly uses ephemeral elliptic-curve key exchange for better performance and forward secrecy, though RSA may still be used for certificates, signatures, or legacy systems.

AES-256-GCM vs RSA-2048: Performance and Security

When discussing these algorithms, developers usually refer to specific key lengths, such as AES-256-GCM and RSA-2048.

Performance is the most obvious difference. AES is much faster for bulk encryption, leveraging hardware acceleration built into modern CPUs. RSA has strict size and performance limits, making it orders of magnitude slower when processing data.

From a security standpoint, AES-GCM protects confidentiality and detects tampering when implemented correctly. However, security always depends on implementation and key management. A strong algorithm is useless if the key is stored in a public log file.

Looking to the future, RSA-2048 remains widely deployed today, but public-key cryptography is more affected by large-scale quantum computing than AES. AES-256 has a much larger security margin against quantum attacks than RSA-2048, meaning post-quantum migration is highly relevant for systems using public-key cryptography.

The decision: why Inkrypt encrypts notes with AES-256-GCM and not RSA

We encrypt note content with AES-256-GCM, using a key derived from your password with PBKDF2-HMAC-SHA256 at 310,000 iterations, a fresh 16-byte salt and a fresh 12-byte IV per save, all through the browser's native Web Crypto API. RSA appears nowhere in the product. Here is the reasoning, because "we use AES" on its own is the kind of claim this article argues you should not accept.

There is no second party to hold a public key. RSA earns its cost when two parties who have never met need to agree on a secret — that is the problem it was built for. Inkrypt's core case is not two parties. It is one person, a password they remember, and a note they come back to. The thing that unlocks a note is knowledge the user already carries, and a password is not a keypair. Introducing RSA would mean generating and storing a private key somewhere, which reintroduces exactly the key-custody problem client-side encryption exists to remove.

Passwords derive symmetric keys, not RSA keys. PBKDF2 turns a password into a 256-bit symmetric key deterministically, so the same password reproduces the same key on any device with no state kept anywhere. There is no comparable path from a memorised password to an RSA private key. Choosing RSA would have forced us to store a key, escrow it, or make users manage a key file — and a service that stores your key is a service that can read your notes.

RSA cannot encrypt a note anyway. RSA encrypts data smaller than its modulus; RSA-2048 with OAEP padding tops out around 190 bytes. Any real note requires the hybrid construction described above — RSA to wrap a symmetric key, AES to do the actual work. So AES would be encrypting the content regardless. The only question was whether to add a key-wrapping layer, and with no remote party to wrap a key for, that layer would add moving parts and a stored private key without adding secrecy.

GCM was the specific choice, not just AES. We use an authenticated mode so tampering with stored ciphertext is detected rather than silently decrypted into altered text. If someone modifies a stored note, the authentication tag fails to verify and decryption refuses to proceed.

What we gave up. This design cannot do the things asymmetric cryptography is genuinely good at. There is no way to let someone encrypt a note to you without a shared secret, no digital signatures, and therefore no cryptographic proof of who wrote a note. If those mattered to the product, RSA or an elliptic-curve scheme would be the right answer and this would be the wrong one. They do not, so it is not.

Where RSA is still involved. Indirectly, in the TLS handshake that protects the connection — although modern TLS 1.3 typically uses elliptic-curve key agreement rather than RSA. That layer is separate from and additional to the encryption applied to your note, which happens before anything is transmitted.

The full specification, including exactly which fields reach our servers, is on the security architecture page. If the browser-based model itself is what you are weighing, client-side vs server-side encryption covers who holds the key in each arrangement.

Strong cryptography still does not rescue a weak password: PBKDF2 makes each guess expensive, it does not make a dictionary word secret. That trade-off, and the others we accept, are documented in our security architecture.

Common AES and RSA Mistakes to Avoid

Even the strongest algorithms fail if they are implemented poorly. Common mistakes developers make include:

• encrypting large data directly with RSA instead of using a hybrid approach
• reusing AES-GCM IVs/nonces, which destroys the security of the cipher
• using weak passwords to generate AES keys
• storing keys in logs, code repositories, or URLs
• confusing encryption (which is reversible with a key) with password hashing (which is one-way)
• assuming encryption hides all metadata (like message size, sender, or timing)
• using outdated or hand-rolled cryptography instead of verified libraries
• treating encryption as absolute protection against compromised devices

FAQ: AES vs RSA Encryption

Q1. Is AES more secure than RSA?

They secure data differently, so direct comparison is difficult. AES-256 has a larger security margin against future quantum attacks than RSA-2048. However, security depends heavily on correct mode selection, key length, and implementation quality.

Q2. Why not encrypt everything with RSA instead of AES?

RSA is mathematically complex and significantly slower than AES. Furthermore, RSA has strict limits on message size; you generally cannot encrypt data that is larger than the RSA key itself. AES is built for high-speed bulk data encryption.

Q3. Which one does Inkrypt use?

Inkrypt uses AES-256-GCM for note encryption. The encryption happens symmetrically in the browser, driven by a key derived from the user's password.

Q4. Should I use AES or RSA for encrypting files?

You should always use AES (or a similarly robust symmetric algorithm like ChaCha20) for encrypting files. If you need to share that file securely, you can use RSA to encrypt the AES key, but the file itself is encrypted with AES.

Q5. Is AES-256-GCM secure?

Yes, AES-256-GCM is secure for browser-based encrypted notes and modern data storage when used correctly. Security depends entirely on using strong keys, never reusing the IV/nonce, and protecting the device performing the encryption.

Q6. What is hybrid encryption?

Hybrid encryption usually means encrypting data with a fast symmetric algorithm (like AES) and then encrypting or protecting that symmetric key with an asymmetric public-key method (like RSA). This provides the speed of AES and the secure key distribution of RSA.

Q7. Does RSA still matter in modern encryption?

Yes. While modern TLS connections often use elliptic-curve cryptography for fast key exchange, RSA is still heavily used for digital certificates, verifying digital signatures, legacy systems, and identity-related cryptographic operations.

Q8. How do quantum computers affect AES vs RSA?

Large-scale quantum computers threaten the math behind RSA. While RSA-2048 is widely deployed today, post-quantum migration is necessary for public-key systems. AES-256, however, is generally considered to have a large enough security margin to withstand quantum attacks.

Q9. Is PBKDF2 encryption?

No. PBKDF2 is a password-based key derivation function. It takes a human-readable password and a cryptographic salt, runs them through thousands of iterations, and outputs a secure key that AES can use for actual encryption.

Q10. Can AES and RSA work together?

Yes, they frequently work together. Can AES and RSA be used together in TLS, encrypted storage, and secure messaging? Absolutely. In fact, using them together in a hybrid encryption model is the standard approach for almost all secure internet communications.

Where to Go Next

To explore more about how encryption protects your data, review our other security guides:

• “Zero-knowledge encryption: what it actually means when we can't see your data”
• “Client-side vs server-side encryption: what changes when your browser holds the key”

This article is about the algorithms themselves and applies wherever you meet them. For the narrower question of how one product uses AES — the exact mode, key length, IV handling and parameters Inkrypt runs — see AES-256-GCM: the cipher behind every Inkrypt note.

Technical claims here follow the primary specifications for the primitives involved: NIST FIPS 197 for AES, NIST SP 800-38D for GCM authenticated encryption, RFC 8017 for RSA (PKCS #1), RFC 8018 for PBKDF2, and RFC 8446 for the TLS 1.3 handshake that puts the two families to work together.