EMZETT.Hybrid Key Methods
In short: A combination of asymmetric and symmetric encryption in order to use the advantages of both methods — this is exactly how every HTTPS connection works, for example.
In more detail: Asymmetric encryption solves the problem of securely exchanging keys, but is slow. Symmetric encryption is fast, but needs a key that has been exchanged securely beforehand. The solution: when the connection is established (e.g. in the TLS handshake), a random session key is exchanged asymmetrically, and the actual data is then encrypted symmetrically with it.
In Depth
The sequence when establishing an HTTPS connection shows the hybrid method in practice:
1. Client and server agree on a cipher suite in the handshake
2. Asymmetric phase: via the server certificate (public key),
a random, short-lived session key is exchanged securely
(in modern TLS via Diffie-Hellman key exchange)
3. Symmetric phase: all further data of the connection is encrypted
symmetrically with this session key (e.g. AES-256)
The difference in speed between the two methods is the real reason for this combination: asymmetric encryption is 100 to 1000 times slower than symmetric, because it’s based on compute-intensive mathematical operations (large prime numbers, elliptic curves), while symmetric encryption works with much simpler bit operations. If you encrypted a whole web page or a video stream completely asymmetrically, it would be noticeably slow — through the combination, the expensive asymmetric part only occurs once when the connection is established, while the bulk of the actual data runs with the fast symmetric method.
The same principle can be found not only in TLS but also in GPG/PGP: a large encrypted file is actually encrypted internally with a random symmetric key, and only this short key itself is additionally encrypted asymmetrically for the recipient and placed in front of the file.
Envelope encryption
This pattern — encrypting data symmetrically and only wrapping the short symmetric key asymmetrically — is often called “envelope encryption”, because the symmetric key is “packed” like a letter in an asymmetrically sealed envelope. Cloud providers such as AWS use this principle in an even more complex form for their encryption services: a data key encrypts the actual data, and a higher-level master key (often kept in specially secured hardware, a hardware security module) in turn encrypts the data key — so the expensive, strictly protected master key rarely has to be touched, while the faster encryption of the actual data is done with frequently changing data keys.
Why not simply asymmetric only?
An obvious approach that’s unsuitable in practice would be to encrypt consistently ONLY asymmetrically, to avoid the complexity of a hybrid method. This fails because of two practical limits: first, the speed already mentioned (asymmetric encryption of entire amounts of data would be noticeably and annoyingly slow at today’s data volumes — video streaming, large downloads). Second, a technical restriction: in practice, RSA can only encrypt amounts of data smaller than the key size itself (with a 2048-bit key, minus padding overhead, only a few hundred bytes) — for larger amounts of data you’d need to split them into many individual blocks anyway, which would make the speed disadvantage even worse.
A practical example: key sizes compared
To get an intuitive feel for the difference in size: a typical symmetric AES-256 session key is only 32 bytes. Even with the slowest asymmetric encryption of this tiny amount of data (the 32 bytes of the session key), the speed disadvantage practically doesn’t matter — compared with asymmetrically encrypting a video stream several gigabytes in size, the difference would be dramatically noticeable.
See also: Asymmetric encryption, Symmetric encryption, Session key