Understanding Symmetric and Asymmetric Encryption, Key Distribution, Digital Signatures, and Their Practical Applications

Many engineers only know how to use symmetric encryption, asymmetric encryption, public keys and private keys without understanding the underlying principles, which often leads to serious mistakes in secure transmission and storage. This article introduces common cryptographic tools and typical scenarios.

Symmetric Encryption

Symmetric encryption uses the same secret for both encryption and decryption. The ciphertext can only be decrypted by someone who possesses that secret.

Example (XOR with a shared key):

# 原文
芹菜，香菜# 约定一个密钥（不能被第三方知道）000111 # 把信息和对称密钥异或运算，得到密文101100

In practice, algorithms such as DES and AES are used, which apply multiple rounds of block cipher operations.

DES

AES

Key length

56 bits

128, 192, 256 bits

Encryption method

Symmetric block cipher

Symmetric block cipher

Rounds

16

10/12/14 (depending on key size)

Security

Broken

Secure

Speed

Slower

Faster

Key Distribution

The main problem of symmetric encryption is how to share the secret key securely between parties.

Two common approaches:

Use a Key Distribution Center (KDC) that generates a session key and encrypts it separately with each party's long‑term key before sending.

Rely on asymmetric techniques (see below) to exchange a secret without a trusted center.

The KDC approach has drawbacks: it requires a always‑available trusted server, the initial distribution of long‑term keys must be protected, and a compromised KDC endangers all communications.

Asymmetric Encryption

Asymmetric (public‑key) cryptography uses a mathematically linked pair of keys: a public key that can be shared openly and a private key that must be kept secret.

Properties:

The public and private keys are strictly one‑to‑one and cannot be interchanged.

Data encrypted with the public key can only be decrypted with the matching private key.

Data signed with the private key can be verified with the public key.

In RSA the keys satisfy public * private mod L = 1 . The public key is used for encryption, while the private key is used for signing.

Key‑Agreement Example (Sunkist‑Cherry Algorithm)

A simplified illustration of the Diffie–Hellman idea using only multiplication (no division). Three participants—Sunkist, Cherry and an eavesdropper Wing—communicate publicly.

Steps:

Both Sunkist and Cherry agree on a public algorithm.

Each chooses a secret private number (5 and 10 respectively).

They agree on a public number (2).

Each multiplies the public number by their private number and shares the result (10 and 20).

Each multiplies the received result by their own private number, obtaining the shared secret 100.

Wing sees the public number and the two intermediate results but cannot compute the secret because division is not allowed in this scenario.

In real systems the Diffie–Hellman protocol uses modular exponentiation, which is easy to compute in one direction but hard to invert.

Digital Signatures

Using RSA, a user generates a key pair, publishes the public key, and signs a document with the private key. Anyone can verify the signature with the public key, proving the document’s origin and preventing repudiation.

Digital Certificates

A trusted Certificate Authority (CA) signs a user’s public key, creating a certificate. When a client needs the public key, it obtains the certificate from the CA, verifies the CA’s signature, and extracts the authentic public key.

SSH Login

Two methods exist: password authentication and public‑key authentication.

Public‑key login steps:

The client generates an RSA/ECC key pair.

The client places the public key on the server (e.g., in authorized_keys ).

After establishing an encrypted channel, the server encrypts a random challenge with the client’s public key and sends it.

The client decrypts the challenge with its private key and returns the plaintext.

The server verifies the response; if it matches, authentication succeeds.

When connecting for the first time, the client sees a message like:

The authenticity of host 'host (12.18.429.21)' can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?

HTTPS Transmission

The TLS handshake combines asymmetric and symmetric cryptography:

The client sends its supported TLS version, cipher suites, and a random nonce.

The server replies with its TLS version, chosen cipher suite, another random nonce, and its certificate.

The client validates the server certificate (expiry, CA trust, signature, hostname match).

The client generates a pre‑master secret, encrypts it with the server’s public key, and sends it.

Both sides derive the session keys from the pre‑master secret and begin symmetric encryption for the rest of the session.

API Calls

Third‑party services often provide a public key and a private key for authentication. The public key can be embedded in client code to encrypt requests; the service decrypts with its private key. Conversely, the server can sign requests with its private key, and the client verifies the signature using the public key.

Summary

Symmetric encryption is fast and is used for bulk data transfer after a secure key has been established, while asymmetric encryption provides secure key exchange, authentication, and digital signatures. Proper key management—keeping private keys secret and using trusted certificates—is essential for maintaining confidentiality and integrity in protocols such as SSH, HTTPS, and API authentication.