Hybrid Encryption: Symmetric and Asymmetric Encryption Combined
Both symmetric and asymmetric encryption has advantages and disadvantages. So, which one should we use? Well, nowadays we often use them together. Asymmetric encryption is often used to exchange private keys between parties securely. In other words, parties who would communicate establish an asymmetric encryption protocol in the beginning just to exchange private keys. When the private key exchange is completed, they keep communicating by using symmetric encryption - which is faster than asymmetric encryption. This is also how SSL/TLS works.
Using symmetric and asymmetric encryption together is also known as Hybrid Encryption.
Here is a sample scenario for hybrid communications:
- Bob wants to send an e-mail to Alice.
- Bob gets Alice’s digital certificate, which includes her name and her public key.
- Alice’s certificate must be signed by a CA (certificate authority). In other words, it must be encrypted with a CA’s private key.
- Bob decrypts Alice’s certificate, by using CA’s public key, and reveals her public key.
- Bob generates a symmetric secret key pair (two identical keys).
- Bob uses Alice’s public key to encrypt one of these symmetric keys.
- The only key that can decrypt this message and reveal the symmetric key is Alice’s private key.
- Therefore, Bob is safe to send this key over the wire, and he sends it to Alice.
- Alice then uses her private key to decrypt the message and to reveal the symmetric key of Bob.
- From now on, they both can use this symmetric key to encrypt and decrypt messages between them.
- Briefly, asymmetric encryption is used to facilitate a key exchange.
This is exactly how SSL/TLS also works!
The content under this title is identical with the steps explained under “Hybrid Encryption for Communications: Messaging” Alice here replaced by google.com. Some additional handshake-specific steps were added to the list.
Bob wants to connect to google.com.
Bob’s browser sends a
ClientHellomessage to the server including:
- Supported highest TLS version
- Supported cryptographic algorithms
At this point, the server knows what the client can do. The server picks one of the supported TLS versions, cryptographic algorithms, and then replies to the client with a
- The chosen TLS version
- The chosen cryptographic algorithm
- Session ID
- Server’s digital certificate: includes the organization name and their public key. This certificate must have been signed by a CA (certificate authority). In other words, it must have been encrypted with a CA’s private key.
Bob decrypts google.com’s certificate, by using CA’s public key, to check certificate validity.
The server sends a
ServerKeyExchangemessage to the client. This message includes:
- Parameters for the key exchange.
- A digital signature (hash) of a set of previous messages so far, signed with the private key of the server. It’s proof that the server is who they say they are.
Bob checks the validity of this digital signature.
Bob generates a symmetric secret key pair (two identical keys).
Bob sends a
ClientKeyExchangemessage to the server and initiates the key exchange process.
Bob uses google.com’s public key to encrypt one of these symmetric keys. The only key that can decrypt this message and reveal the symmetric key is google.com’s private key. Therefore, Bob is safe to send this key over the wire, and he sends it to google.com.
Bob sends a
ClientFinishedmessage, including digital signature (hash) of all previous messages so far.
google.com then uses their private key to decrypt the message and to reveal the symmetric key of Bob.
google.com sends a
ServerFinishedmessage, including the digital signature (hash) of all previous messages so far. By doing so, both parties can be sure that no one intercepted the communication (man-in-the-middle).
From now on, they both can use this symmetric key to encrypt and decrypt messages between them. Briefly, asymmetric encryption is used to facilitate a key exchange.
Client Server ClientHello (empty SessionTicket extension)--------> ServerHello (empty SessionTicket extension) Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> NewSessionTicket [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
SSL or TLS?
Often SSL and TLS are used interchangeably. However, they aren’t identical terms. SSL (Secure Sockets Layer) is a deprecated cryptographic protocol and totally by TLS (Transport Layer Security). The last time SSL was updated was in 1996.
SSL and TLS have three main purposes:
- Confidentiality (Encryption): Data is only accessible by Client and Server.
- Integrity (Hashing): Data isn’t modified between Client and Server.
- Authentication (PKI): Client/Server is indeed who they say they are.
TLS Downgrade Attack
Old versions of TLS are prone to “Downgrade Attack”. In this attack type, the client (web browser) fakes the highest
supported TLS version with an old version. For example, the client requests TLS 1.0, even though it can support TLS 1.3.
By doing so, the attacker tries to be served by a weaker TLS version and manipulate it. To prevent your systems from
this attack, you should configure your server not to support lower TLS versions. In the latest version of TLS, the
ServerFinished messages are added to eliminate these downgrade attacks.
Who are these CAs (Certificate Authorities) anyway?
- Today, 5 organizations (SSL certificate issuers) secure 98% of the Internet:
- IdenTrust (51.9%)
- Let’s Encrypt
- DigiCert (19.4%)
- Sectigo (17.5%)
- GoDaddy (6.9%)
- GlobalSign (2.9%)
- IdenTrust (51.9%)
However, they don’t issue all certificates themselves. Often we obtain our certificates from intermediate CAs, which is a topic of PKI (Public Key Infrastructure).
Public Key Infrastructure (PKI)
CA’s use self-signed certificates! But why? Because we need to trust someone, at the top! At the top, there is a CA, which has a self-signed certificate, such as IdenTrust. Then there are intermediate CAs, under the root CA, but their certificates aren’t self-signed. Instead, they are signed by a CA (with CA’s private key). These intermediate CAs can issue (sign) certificates for us. This is known as the “Chain of Trust”. We trust our certificate provider, our certificate provider trusts the root CA, and so on. By the way, it’s also possible to set up your own corporate CA if you don’t want to pay for certificates every single time.
In other to verify the Chain of Trust, we use their public keys. Let’s say google.com has a certificate issued by CA1. To verify this, we check the certificate of CA1. The thing is, the certificate of CA1 is issued by RootCA. Now we need to verify everything one by one. Our browser will verify the RootCA by checking the local trust store. Then the certificate of CA1 by using the public key of RootCA. Then the certificate of google.com, by using the public key of CA1.
Three entities form a PKI:
- Client: Needs to connect securely or verify identity.
- Server: Needs to prove its identity.
- Certificate Authority: Validate identities & generate certificates.