Why use symmetric encryption with Public Key?

Question

A. From what I heard (and I am beginner at a security/cryptography), if you have a payload that is very large, asymmetric is a no-go.

B. Also, if you do have secret symmetric (e.g. AES) keys, you might not want to share them with others, if they have high importance to you.

I am trying to understand things and I cannot find good enough internet resources explaining this use case.

Here is the reasons I have thought of, for doing such an encryption:

1. asymmetric encryption is not available; e.g. due to large data size
2. symmetric keys are available but you do not want them to be shared with other parties
3. sender/encryptor needs to send data to the receiver securely (encrypted)

Please validate/criticise my ideas or add others.

Answer 1

I think you're looking for Hybrid cryptosystems.

As you correctly noted it's not only unsafe to encrypt large data with a asymmetric system it's also very slow compared to symmetric systems. That's why we usually use both of these systems together (hence hybrid) to "fill each other's gaps".

We share a symmetric key using asymmetric cryptography. The advantage is that we only have to share the symmetric key once at the beginning of a session and all succeeding messages will be encrypted using the symmetric key. The asymmetric system provides safe key-sharing and the symmetric system guarantees fast encryption / decryption.

B. Also, if you do have secret symmetric (e.g. AES) keys, you might not want to share them with others, if they have high importance to you.

That's true, but we always create new keys for each communication channel, we don't use a single symmetric key for all communication.

Answer 2

Why use symmetric encryption with Public Key?

• The scrambling in public-key encryption systems is often limited to very specially chosen inputs. For example, RSA with modulus $n$ is good at scrambling uniform random integers between $0$ and $n$, but bad at scrambling random English text. In contrast, the stream cipher ChaCha can securely encrypt any bit string you want. (But make sure to use it only through an authenticated cipher like ChaCha/Poly1305.)

  Practical public-key encryption schemes based on RSA either go through contortions to shoehorn a very short message into something that's close to a uniform random integer between $0$ and $n$ using hash functions (RSAES-OAEP—which is essentially always used to encrypt a short symmetric key anyway!), or just return a key for you to use with symmetric-key cryptography along with a ciphertext concealing the key (RSA-KEM) rather than letting you choose an input at all.

• Some public-key encryption systems doesn't even work by scrambling user-chosen inputs at all, but instead only provide a way for the sender and receiver to agree on a key that can be used later on—for symmetric cryptography. For example, public-key encryption based on the elliptic curve Curve25519 usually works by essentially doing a Diffie−Hellman key agreement between the recipient's long-term key and a one-time key you generate on the spot just for one message. Then you can use the key for a symmetric-key authenticated cipher. The recipient can later recover the one-time key from the ciphertext using their private key.

  The modern approach to public-key encryption today—as seen in, e.g., the NIST PQC process to identify public-key cryptography standards for a post-quantum world—is key encapsulation mechanisms: given a public key, a KEM randomly generates a one-time key and a ciphertext encapsulating it; then you use the one-time key for a symmetric-key authenticated cipher to actually process a message.

• Symmetric-key cryptography is much easier than public-key cryptography. Providing a way to scramble a message using a public key so that it can be unscrambled only with the corresponding private key requires a rich mathematical theory to relate the public key and private key. But that rich mathematical theory is also rife with ideas that an adversary can use to attack the cryptosystem.

  • The original RSA proposal from the 1970s is totally broken today because of dramatic cryptanalytic advances against that rich mathematical theory—the quadratic sieve, the elliptic-curve method of factoring, the number field sieve, lattice attacks, broadcast attacks, and more.
  • The literature is full of broken ideas for elliptic-curve cryptosystems since the idea of elliptic-curve cryptography was proposed in the 1980s—anomalous curves, twist-insecure curves, curves with multiplicative transfers, and so on.
  • Likewise lattice-based cryptography, isogeny-based cryptography, etc.

  In contrast, ChaCha is designed not to have any interesting mathematical relations when the key is uniform random, and the cryptography community has very high confidence in it that has remained high since it was created over a decade ago. Even if someone invented a quantum computer, ChaCha would not be threatened.

• Symmetric-key cryptography is much cheaper than public-key cryptography. We can take a short uniform random 256-bit secret and expand it into a very long secret using ChaCha at gigabits per second on a modern CPU. In contrast, a single RSA private-key operation at a modest security level costs millions of CPU cycles to process 2048 bits of data, handling at best kilobytes per second. Even Curve25519 operations cost hundreds of thousands of cycles. In general the fastest, smallest, cheapest public-key cryptography is nowhere near competitive with symmetric-key cryptography in all dimensions.

  We can use part of the long secret generated by ChaCha like a one-time pad to encrypt a message, and part of it as the key to a one-time authenticator like Poly1305 to prevent forgery; then anyone else who has the same key can verify the message and decrypt it at the same speed. Of course, anyone who can encrypt and authenticate messages with ChaCha/Poly1305 can also decrypt and forge messages—which is why we sometimes need public-key cryptography, if we want to separate the ability to send and sign messages from the ability to read and verify messages.

---

In general, the only reason to use public-key encryption is that you want to separate the power to send a confidential message from the power to open the confidential message. That way, for example, anyone can send a journalist a confidential message to their anonymous SecureDrop box, but only the journalist can open it. There's no reason to insist on feeding the message directly into the public-key math without going through a symmetric-key authenticated cipher—that's neither necessary for the goal of separating these powers, nor helpful.

What you are asking about is sometimes called ‘hybrid encryption’. This is a technical term of art that is not very helpful for a lay audience, because all serious public-key encryption that you are likely to encounter is ‘hybrid encryption’—only exotic applications like electronic voting systems with zero-knowledge proofs of correctness which require extreme expert care to implement will use public-key encryption primitives like Elgamal directly without ‘hybrid encryption’.

Similar concerns apply to public-key signature schemes: You use them only when you need the power to sign a message to be separate from the power to verify a message. And even then, the security of a public-key signature scheme invariably relies on hashing the message first before feeding it into the public-key math.

Answer 3

asymmetric encryption is not available; e.g. due to large data size

Besides having bigger ciphertext representation, it's also proven to be slower than enciphering data with symmetric schemes. But recall that digital signatures are also available to perform verification.

symmetric keys are available but you do not want them to be shared with other parties

Okay, but how do you solve the problem of not exchanging symmetric keys but both Alice and Bob obtaining a shared secret key?

sender/encryptor needs to send data to the receiver securely (encrypted)

It's not necessary to encipher the data for exchaning messages that later allow both parties to establish a secret key. It could be some form of challenge or public values that feeded to a trapdoor-permutation function in some sort of sequence-order gives a common value to Alice and Bob. Moreover, perfect-forward secrecy could be achieved not using a long-term private key that decipher what Alice sends to Bob.

Now to answer your question, the best idea is to use a mix of both symmetric and asymmetric schemes. As seen in key exchange protocols, the main idea is to use an asymmetric scheme that permits Alice and Bob to reach a common value, then that common value is expanded in some way to create secret shared keys for a symmetric scheme and authentication keys for any MAC function.

Summarizing, the whole is known as Hybrid cryptography and is present for example in every connection establishment under HTTPS. Reading any RFC of TLS would give you an idea after looking for the right definition of what hybrid means here.

Answer 4

An analogy that I find helpful for newer people is to think of the:

• Symmetric algorithm as a physical key and an associated "symmetric type of" safe
• Asymmetric algorithm as both
  • an open padlock (your public key) that also has an associated "asymmetric lockbox"
  • the physical key that unlocks the padlock (associated private key)
• The Password Based Key Derivation Function (e.g. PBKDF2) as being a "combination safe" dial mechanism (that uses the symmetric safe "underneath" it)

You first generate your asymmetric key pair. The public key can be given to anyone. It is like an open padlock. If someone writes a message to you and puts it in an "asymmetric lockbox," they can lock the lockbox with your public key by "closing the padlock," and then even they can't open it again without the private key. However, the message itself isn't actually what is protected with this padlocked lockbox, for although it is an awesome tool and effectively (currently) impossible to break into when used properly, it really isn't that strong or sophisticated in numerous other ways (it is a bit recalcitrant of a padlock that is slow to force closed, and the lockbox is known to be drillable by powerful quantum computers, and you can't nicely fit much into it). More on this later.

Depending on the scenario, mostly whether the key pair is long term or ephemeral, you may want to locally encrypt your private key symmetrically. This is typically done with a symmetric algorithm keyed with a PBKDF (I use PBKDF generically; most don't seem to unfortunately. I don't know what else to call the generic construct). You provide a password to the PBKDF, and it outputs a key. You can think of it as being like a combination safe (when it is coupled with a symmetric algorithm that actually encrypts things with it; the PBKDF is just the dial mechanism; it uses the symmetric safe for security of what is stored). The U.S. courts see it as being analogous to a combination dial because what is needed to unlock it is stored in your mind instead of in a drawer like a regular key is (such regular keys can also be used: they would be called keyfiles in this context, and have less legal protection in the USA because of not being stored in one's mind, but I digress). Now you only have your private key in plaintext when you need to use it; upon needing it, you type in your password (dial in the combination, by analogy).

So, when people want to send you a message, they actually put it in a very strong key based symmetric safe that is well oiled, quick to open and shut, resists "quantum drills," and can hold a lot in it. But how can they now ship this securely to you? If they locked the key in the safe, you couldn't use it to open the safe. If they shipped it along outside of it, anyone who intercepted the shipment could open it and read the message to you. This is where the open padlock comes into play. They put the key (called a "session key" and generated randomly per message) into an asymmetric "lockbox" and lock it with your padlock (after some effort to get the thing to shut -- it isn't the most friendly locking mechanism, nor the strongest, but eventually it can be forced shut).

Note that the padlock is a magical replicating one, and that you effectively have unlimited of them in the open state.

Now they can send you both the lockbox and the safe.

When you get the lockbox and the safe delivered to you, first you use your combination dial (type your password in) to unlock your local safe (decrypt your locally symmetrically encrypted private asymmetric key) to be able to take your private asymmetric key out of it. Second, you use this private asymmetric key to open the closed padlock on the lockbox, which allows you to take out the session key. You then use the session key to open the safe and get your message out of it.

That neglects authentication and other steps, and it is clearly an analogy; however, I believe it is a highly useful analogy for newer people. The use of the open padlock is obvious: how else can you have the ability to lock stuff for someone else to open? If you use a regular key lock, you both need the key, but if you don't both have it then how can you securely send it to the person who needs it? Certainly not outside of protection, for if you were to do so (in our simplified analogy not concerned with polymorphism and the like, anyway) you may as well have saved on shipping costs by not sending the safe or lockbox in the first place.

The key locked safes just have nicer mechanisms in and of themselves, and are nicer safes, so they are used when they can be, but you simply need the open padlock style mechanism so that you can send the key to the key safe, in the smaller and less secure lockbox. Both are sent in the same "shipment," with your message itself kept in the superior key locked safe because there is no need for anything but the session key to be protected with the comparatively not so good (but crucial) padlock mechanism and lockbox.