Cryptography From Zero: The Science Behind TLS

We now go one level deeper.

So far:

DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP

We learned that TLS uses cryptography.

Now we ask:

What is cryptography actually doing mathematically?

1. The Four Fundamental Ideas

Modern web security is built from several different mathematical tools:

Cryptography
│
├── Encryption
├── Hashing
├── Digital signatures
└── Key exchange

They solve different problems.

2. Encryption

Encryption converts readable information:

PLAINTEXT

into protected information:

CIPHERTEXT

Conceptually:

Plaintext
   │
   │ Key
   ▼
Encryption
   │
   ▼
Ciphertext

To recover it:

Ciphertext
   │
   │ Key
   ▼
Decryption
   │
   ▼
Plaintext

3. Example

Suppose:

Plaintext:

HELLO

Encryption might produce:

Ciphertext:

8F4A91...

The ciphertext should not reveal the plaintext to someone who doesn’t possess the necessary key.

The actual algorithms are much more mathematically sophisticated.

4. Two Major Types of Encryption

There are two fundamental categories:

Symmetric encryption
Asymmetric cryptography

5. Symmetric Encryption

Symmetric encryption uses a shared secret key.

             SECRET KEY
                 │
                 ▼
Plaintext → Encryption → Ciphertext
                              │
                              ▼
                         Decryption
                              │
                              ▼
                          Plaintext

The communicating parties need access to the appropriate secret key.

6. Example Symmetric Algorithm

A major modern algorithm is:

AES

Advanced Encryption Standard.

Common configurations include:

AES-128
AES-256

TLS can use AES-GCM constructions.

7. Why AES Is Fast

AES is designed for efficient implementation in software and hardware.

Modern CPUs often have specialized instructions for AES.

Therefore it is suitable for:

Web pages
Images
Videos
API traffic
Database connections
Large files

8. Asymmetric Cryptography

Asymmetric cryptography uses a key pair:

Public key
Private key

Conceptually:

              KEY PAIR
                 │
        ┌────────┴────────┐
        ▼                 ▼
   Public key        Private key

They are mathematically related.

9. Public Key

The public key can be distributed.

For example:

Server
 ↓
Certificate
 ↓
Public key
 ↓
Browser

There is no need to keep the public key secret.

10. Private Key

The private key must remain secret.

Your server has:

/etc/letsencrypt/live/templates.cresignsys.com/privkey.pem

That is sensitive key material.

11. Why Two Keys?

The key pair allows cryptographic operations where possession of the private key proves control of the corresponding public key.

One major use is:

Digital signatures

12. Digital Signature

A digital signature allows someone to verify:

The holder of the private key authorized this data.

Conceptually:

Data
  │
  ▼
Hash
  │
  ▼
Private key
  │
  ▼
Digital signature

The recipient can use the public key to verify the signature.

13. Signature Verification

Conceptually:

Data
 │
 ▼
Hash ────────────┐
                 │
Signature ───────┤
                 ▼
            Verification
                 │
             VALID / INVALID

The actual mathematical operations depend on the signature algorithm.

14. Digital Signature Is Not Encryption

This distinction is extremely important.

Encryption:

Goal:
Keep information secret

Digital signature:

Goal:
Prove authenticity/integrity

So:

Encryption ≠ Digital signature

15. Hashing

Hashing is another fundamental cryptographic operation.

A hash function takes arbitrary-length input and produces a fixed-size output.

Conceptually:

Input
  │
  ▼
Hash function
  │
  ▼
Digest

16. Example

Suppose:

Input:

Hello

A cryptographic hash produces a digest.

For SHA-256, the output is:

256 bits

or:

32 bytes

usually represented as:

64 hexadecimal characters

17. SHA-256

One important cryptographic hash function is:

SHA-256

SHA means:

Secure Hash Algorithm

SHA-256 produces:

256-bit digest

18. Hash Is Not Encryption

This is a common beginner mistake.

Encryption:

plaintext
 ↓
ciphertext
 ↓
decryption
 ↓
plaintext

Hashing:

input
 ↓
hash
 ↓
digest

A cryptographic hash is designed to be one-way in practice.

19. Why Hashes Are Useful

Hashes can help with:

Integrity verification
Digital signatures
Password storage systems
Certificates
Software verification
Content addressing
Blockchain systems

20. Tiny Change, Huge Difference

A good cryptographic hash has an avalanche effect.

Suppose:

Input A:
Hello

and:

Input B:
hello

Changing one character can produce a dramatically different digest.

Conceptually:

Hello
 ↓
HASH A

hello
 ↓
HASH B

The outputs should look unrelated.

21. Hash Collision

A collision occurs when:

Input A
 ↓
Hash X

Input B
 ↓
Hash X

Cryptographic hash functions are designed to make finding such collisions computationally difficult.

22. SHA-1 vs SHA-256

Older systems may still mention:

SHA-1

but SHA-1 is no longer considered suitable for modern collision-resistant security applications.

Modern systems generally use stronger algorithms such as:

SHA-256
SHA-384
SHA-512

depending on the application.

23. Hashing and Passwords

Passwords are generally not stored as plaintext.

Instead, password systems use password hashing mechanisms.

Conceptually:

User enters password
       ↓
Password hashing
       ↓
Stored password verifier

Modern password storage should use dedicated password hashing algorithms such as:

Argon2
bcrypt
scrypt
PBKDF2

rather than simply storing:

SHA-256(password)

24. Why Password Hashing Is Different

A normal cryptographic hash is designed to be extremely fast.

That’s useful for many applications.

But for password storage, you actually want an attacker to have a harder time trying billions of guesses.

Therefore password hashing algorithms are deliberately:

Computationally expensive
Memory-intensive where appropriate
Salted

25. Salt

A salt is a random value associated with a password hash.

Conceptually:

Password
   +
Random salt
   ↓
Password hashing
   ↓
Verifier

Two users with the same password should not automatically have identical stored password hashes.

26. Salt vs Encryption Key

Don’t confuse:

Salt

with:

Encryption key

A salt is generally not secret.

A private/encryption key is secret.

27. Randomness

Cryptography depends heavily on:

Randomness

Bad randomness can destroy otherwise strong cryptographic systems.

For example:

Weak random number
 ↓
predictable key
 ↓
broken security

Modern operating systems provide cryptographically secure randomness mechanisms.

28. Entropy

Entropy is a way of describing unpredictability.

Conceptually:

Predictable
   ↓
Low entropy

Unpredictable
   ↓
High entropy

Cryptographic keys need sufficient unpredictability.

29. Key Space

Suppose a key has:

128 bits

There are:

2^128

possible bit patterns.

That’s an enormous number.

For a 256-bit key:

2^256

possible values.

30. Why Key Length Matters

A larger key space generally makes brute-force searching harder.

But:

Bigger is not automatically better.

The security depends on the algorithm, implementation, protocol, and threat model.

31. Brute Force

Suppose an attacker doesn’t know a secret key.

They could theoretically try:

Key 1
Key 2
Key 3
...

This is:

Brute-force attack

Good cryptographic systems make exhaustive searching computationally infeasible.

32. Public-Key Algorithms

Two major families you’ll encounter are:

RSA
ECC

33. RSA

RSA is a public-key cryptosystem based on mathematical properties related to large integer factorization.

It has historically been widely used for:

Encryption
Digital signatures
TLS certificates
SSH

Modern TLS 1.3 uses RSA signatures in some certificate configurations, but RSA key exchange itself was removed from TLS 1.3.

34. ECC

ECC means:

Elliptic Curve Cryptography

It uses mathematical structures involving elliptic curves over finite fields.

ECC can provide strong security with comparatively smaller key sizes than traditional RSA.

35. ECDSA

ECDSA means:

Elliptic Curve Digital Signature Algorithm

It is used for digital signatures.

Conceptually:

Private ECC key
      ↓
ECDSA signature
      ↓
Public ECC key
      ↓
Verification

36. ECDHE

ECDHE means:

Elliptic Curve Diffie-Hellman Ephemeral

It is used for key agreement.

Conceptually:

Client ephemeral key
        +
Server ephemeral key
        ↓
Shared secret

The secret itself is not directly transmitted.

37. ECDSA vs ECDHE

This distinction is important:

ECDSA
 ↓
Digital signatures

while:

ECDHE
 ↓
Key agreement

They solve different problems.

38. TLS Uses Several Algorithms Together

A TLS connection can conceptually involve:

Certificate
    ↓
ECDSA/RSA signature
    ↓
Authentication

ECDHE
    ↓
Shared secret

AES-GCM / ChaCha20-Poly1305
    ↓
Application-data encryption

SHA-256-family primitives
    ↓
Hashing / transcript/key-derivation functions

The exact algorithms depend on the TLS configuration.

39. TLS Is a Protocol, Not One Algorithm

This is another major concept.

TLS is not:

"an encryption algorithm"

TLS is a protocol that defines how multiple cryptographic mechanisms work together.

Think:

TLS
├── Authentication
├── Key exchange
├── Key derivation
├── Encryption
├── Integrity protection
└── Protocol state

40. Key Exchange

The browser and server need shared secret material.

But imagine the Internet is being observed.

You cannot simply send:

SECRET KEY

in plaintext.

So TLS uses key agreement.

41. Diffie-Hellman Idea

The fundamental idea:

Client
   │
   │ public information
   ▼
Server

Both sides combine public information with their own secret values.

They independently calculate the same shared secret.

42. Observer

An observer sees:

Client public value
Server public value

but does not know:

Client private value
Server private value

Therefore the observer should not be able to calculate the shared secret under the cryptographic assumptions.

43. Ephemeral Keys

TLS 1.3 normally uses ephemeral key exchange.

Conceptually:

Connection 1
 ↓
Temporary keys

Connection 2
 ↓
Different temporary keys

Connection 3
 ↓
Different temporary keys

This contributes to forward secrecy.

44. Forward Secrecy

Suppose an attacker steals your server’s long-term private key tomorrow.

With properly implemented ephemeral key exchange, previously captured TLS sessions should not automatically become decryptable.

This is called:

Forward secrecy

or:

Perfect Forward Secrecy

in the relevant context.

45. Certificate Private Key

Now return to your server:

privkey.pem

This is associated with your certificate.

It establishes control of the certificate’s public key and supports server authentication/signatures.

It is not simply the bulk encryption key for all traffic.

46. Session Key

During TLS:

ECDHE
 ↓
shared secret
 ↓
TLS key schedule
 ↓
session traffic keys

These session keys protect the actual application data.

47. Key Derivation

The shared secret isn’t simply used directly as:

AES key

TLS 1.3 uses a key schedule based on:

HKDF

48. HKDF

HKDF means:

HMAC-based Extract-and-Expand Key Derivation Function

It derives cryptographically strong keys from input key material.

Conceptually:

Shared secret
      ↓
HKDF
      ↓
Multiple derived secrets
      ↓
Traffic keys

49. HMAC

HMAC means:

Hash-based Message Authentication Code

It combines:

Hash function
+
Secret key

to create an authentication value.

Conceptually:

Message
+
Secret key
 ↓
HMAC
 ↓
Authentication value

50. HMAC vs Hash

Hash:

Message
 ↓
Hash

HMAC:

Message
+
Secret key
 ↓
HMAC

The secret key is what makes HMAC different.

51. AEAD

TLS 1.3 uses:

AEAD

Authenticated Encryption with Associated Data.

AEAD provides:

Confidentiality
+
Integrity/authentication

for protected records.

Examples:

AES-GCM
ChaCha20-Poly1305

52. Associated Data

Some information doesn’t need to be encrypted but should still be authenticated.

AEAD supports:

Encrypted data
+
Authenticated associated data

This is useful in protocol design.

53. The Cryptographic Toolbox

At this point, think of cryptography as a toolbox:

Hash
 ↓
Fingerprint / digest

HMAC
 ↓
Keyed integrity/authentication

Digital signature
 ↓
Publicly verifiable authentication

ECDHE
 ↓
Key agreement

AES-GCM
 ↓
Fast authenticated encryption

ChaCha20-Poly1305
 ↓
Fast authenticated encryption

HKDF
 ↓
Derive session keys

54. TLS Combines the Toolbox

Conceptually:

                  TLS
                   │
       ┌───────────┼────────────┐
       ▼           ▼            ▼
Authentication  Key Exchange  Encryption
       │           │            │
       ▼           ▼            ▼
Certificate      ECDHE        AES-GCM
Signature        HKDF         ChaCha20

55. Certificate Chain Is Also Cryptography

Your Let’s Encrypt certificate is digitally signed.

Conceptually:

Let's Encrypt CA
       │
       │ private signing key
       ▼
Server certificate
       │
       ▼
Browser verifies

The browser trusts the CA through its trust store.

56. Chain of Trust

Imagine:

Root CA
   │
   │ signs
   ▼
Intermediate CA
   │
   │ signs
   ▼
Your certificate

The browser starts from a trusted root and verifies the signatures down the chain.

57. Why an Attacker Can’t Just Create a Certificate

Suppose an attacker creates:

fake certificate

for:

templates.cresignsys.com

The attacker cannot simply make the browser trust it.

The certificate would need to chain to a trusted authority or otherwise be explicitly trusted by the client.

58. Certificate Validation

The browser checks multiple things.

Conceptually:

Certificate
 │
 ├── Is it signed correctly?
 ├── Is the issuer trusted?
 ├── Is it currently valid?
 ├── Does hostname match?
 ├── Are usages appropriate?
 └── Does the chain validate?

If validation fails, the browser warns or blocks depending on the situation.

59. Certificate Expiration

Your certificate has:

notBefore
notAfter

If:

current date > notAfter

the certificate is expired.

The browser can reject it.

60. Domain Name Validation

The browser checks the requested hostname against the certificate’s SAN entries.

For example:

Requested:
templates.cresignsys.com

Certificate:
templates.cresignsys.com

Match:

VALID

61. Wrong Certificate

Suppose Nginx accidentally serves:

shop.cresignsys.com

for:

templates.cresignsys.com

The certificate hostname may not match.

Then the browser can report a certificate-name error.

62. SNI + Certificate Selection

This explains another important hosting concept:

Browser
 ↓
SNI = templates.cresignsys.com
 ↓
Nginx
 ↓
select correct TLS server configuration
 ↓
fullchain.pem
 ↓
certificate for templates.cresignsys.com

63. One IP, Multiple Certificates

A single IP can host:

templates.cresignsys.com
shop.cresignsys.com
learn.cresignsys.com

Nginx can serve different certificates based on the requested hostname/SNI.

This is one of the foundations of shared hosting.

64. Why TLS Is Layered

TLS doesn’t replace:

DNS
TCP
HTTP

Instead:

DNS
 ↓
find destination

TCP
 ↓
transport bytes

TLS
 ↓
secure the transport/application data

HTTP
 ↓
web protocol

Each layer has a different job.

65. A Real HTTPS Request

Let’s trace your website:

Browser
   │
   ▼
DNS
   │
   ▼
YOUR PUBLIC IP
   │
   ▼
TCP 443
   │
   ▼
SYN
   │
   ▼
SYN-ACK
   │
   ▼
ACK
   │
   ▼
TLS ClientHello
   │
   │ SNI = templates.cresignsys.com
   ▼
Nginx
   │
   ▼
TLS Certificate
   │
   ▼
Certificate validation
   │
   ▼
ECDHE key exchange
   │
   ▼
HKDF key derivation
   │
   ▼
Session keys
   │
   ▼
Encrypted HTTP

66. Then Nginx

After TLS has established secure communication:

HTTP request
     ↓
Nginx
     ↓
server_name
     ↓
website root

For WordPress:

Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

67. The Return Path

The response follows the reverse conceptual path:

MySQL / WordPress
       ↓
PHP-FPM
       ↓
Nginx
       ↓
HTTP response
       ↓
TLS encryption
       ↓
TCP
       ↓
IP
       ↓
Internet
       ↓
Browser

68. Why This Matters for Hosting

When you understand cryptography, you can diagnose problems more intelligently.

For example:

DNS error

is not the same as:

TCP error

which is not the same as:

TLS certificate error

which is not the same as:

HTTP 502

69. Four Different Failures

DNS

Domain doesn't resolve

TCP

Connection refused
Connection timed out

TLS

Certificate expired
Hostname mismatch
Untrusted certificate
TLS negotiation failure

HTTP/Application

These belong to different layers.

70. Your `fullchain.pem`

Think of it as:

"Here is my certificate and the intermediate chain needed to establish trust."

71. Your `privkey.pem`

Think of it as:

"This is the secret private key corresponding to my certificate's public key."

Never expose it publicly.

72. Let’s Encrypt

Think of Let’s Encrypt as:

Certificate Authority
+
ACME service

not:

encryption engine

73. Certbot

Think of Certbot as:

ACME client

that automates:

Request
Validation
Download
Installation
Renewal

74. Nginx

Think of Nginx as:

Web server
+
reverse proxy
+
TLS endpoint

among other capabilities.

In your setup, it terminates TLS for the website.

75. TLS Termination

The term:

TLS termination

means the encrypted TLS connection ends at a particular component.

In your basic architecture:

Browser
   │
   │ encrypted TLS
   ▼
Nginx
   │
   │ decrypted HTTP/application handling
   ▼
PHP-FPM

Nginx is therefore the TLS termination point.

76. Reverse Proxy Later

In a more advanced architecture:

Internet
   ↓
Load Balancer
   ↓
Nginx
   ↓
Application

TLS might terminate at the load balancer instead.

This is why understanding TLS termination becomes important in larger hosting systems.

77. The Security Boundary

Suppose TLS terminates at Nginx:

Internet
   │
   │ encrypted
   ▼
Nginx
   │
   │ decrypted
   ▼
PHP-FPM

The traffic between Nginx and PHP-FPM is then no longer the same Internet-facing TLS connection.

For local communication on the same server, that may be acceptable depending on the architecture.

78. Deepest Basic Model

At the deepest conceptual level:

             TRUST
               │
               ▼
          Certificate
               │
               ▼
        Public/Private Keys
               │
               ▼
        Authentication
               │
               ▼
          Key Exchange
               │
               ▼
        Shared Secret
               │
               ▼
           Key Derivation
               │
               ▼
          Session Keys
               │
               ▼
       Authenticated Encryption
               │
               ▼
          Protected Data

That is the cryptographic foundation of HTTPS.

79. Memorize This Table

Technology	Main purpose
Hash	Fixed-length digest
SHA-256	Cryptographic hash
HMAC	Keyed authentication/integrity
RSA	Public-key cryptography/signatures
ECC	Public-key cryptography family
ECDSA	Digital signatures
ECDHE	Key agreement
HKDF	Key derivation
AES-GCM	Authenticated encryption
ChaCha20-Poly1305	Authenticated encryption
X.509	Certificate format/infrastructure
TLS	Secure communication protocol
ACME	Automated certificate management
Let’s Encrypt	Certificate Authority
Certbot	ACME client
Nginx	TLS endpoint/web server

80. One Diagram to Remember

                  HTTPS
                    │
                    ▼
                   TLS
                    │
       ┌────────────┼────────────┐
       │            │            │
       ▼            ▼            ▼
 Certificate     ECDHE         AEAD
       │            │            │
       ▼            ▼            ▼
 Authentication  Key exchange  Encryption
       │            │            │
       └────────────┼────────────┘
                    ▼
               Secure session
                    │
                    ▼
                   HTTP
                    │
                    ▼
                  Nginx

Lesson 039 Summary

The essential concepts are:

Hash
=
fingerprint/digest

Encryption
=
confidentiality

Digital signature
=
authentication + integrity evidence

ECDHE
=
shared-secret key agreement

HKDF
=
derive session keys

AES-GCM / ChaCha20-Poly1305
=
protect application data

Certificate
=
binds an identity to a public key

Let's Encrypt
=
Certificate Authority

Certbot
=
ACME automation client

TLS
=
protocol combining these technologies

And your actual HTTPS system becomes:

DNS
 ↓
TCP
 ↓
TLS
 ├── Certificate
 ├── SNI
 ├── Authentication
 ├── ECDHE
 ├── HKDF
 └── AES-GCM / ChaCha20-Poly1305
 ↓
HTTP
 ↓
Nginx
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

Next Lesson — 040

X.509 Certificates — The Exact Science Behind `fullchain.pem`

We will go inside the certificate itself:

X.509
 ↓
Certificate structure
 ↓
Subject
 ↓
Issuer
 ↓
Serial number
 ↓
Validity
 ↓
Subject Alternative Name
 ↓
Public key
 ↓
Key usage
 ↓
Extended key usage
 ↓
Basic constraints
 ↓
CA signature
 ↓
Root certificate
 ↓
Intermediate certificate
 ↓
Leaf/server certificate
 ↓
fullchain.pem

Then we will inspect your actual certificate with openssl and understand every important field that appears inside it.

CresignSys Learn — Lesson 039

Cryptography From Zero: The Science Behind TLS

1. The Four Fundamental Ideas

2. Encryption

3. Example

4. Two Major Types of Encryption

5. Symmetric Encryption

6. Example Symmetric Algorithm

AES

7. Why AES Is Fast

8. Asymmetric Cryptography

9. Public Key

10. Private Key

11. Why Two Keys?

Digital signatures

12. Digital Signature

13. Signature Verification

14. Digital Signature Is Not Encryption

15. Hashing

16. Example

17. SHA-256

SHA-256

Secure Hash Algorithm

18. Hash Is Not Encryption

19. Why Hashes Are Useful

20. Tiny Change, Huge Difference

21. Hash Collision

22. SHA-1 vs SHA-256

23. Hashing and Passwords

24. Why Password Hashing Is Different

25. Salt

26. Salt vs Encryption Key

27. Randomness

Randomness

28. Entropy

29. Key Space

30. Why Key Length Matters

31. Brute Force

Brute-force attack

32. Public-Key Algorithms

33. RSA

34. ECC

Elliptic Curve Cryptography

35. ECDSA

Elliptic Curve Digital Signature Algorithm

36. ECDHE

Elliptic Curve Diffie-Hellman Ephemeral

37. ECDSA vs ECDHE

38. TLS Uses Several Algorithms Together

39. TLS Is a Protocol, Not One Algorithm

40. Key Exchange

41. Diffie-Hellman Idea

42. Observer

43. Ephemeral Keys

44. Forward Secrecy

Forward secrecy

Perfect Forward Secrecy

45. Certificate Private Key

46. Session Key

47. Key Derivation

HKDF

48. HKDF

HMAC-based Extract-and-Expand Key Derivation Function

49. HMAC

Hash-based Message Authentication Code

50. HMAC vs Hash

51. AEAD

AEAD

52. Associated Data

53. The Cryptographic Toolbox

54. TLS Combines the Toolbox

55. Certificate Chain Is Also Cryptography

56. Chain of Trust

57. Why an Attacker Can’t Just Create a Certificate

58. Certificate Validation

59. Certificate Expiration

60. Domain Name Validation

61. Wrong Certificate

62. SNI + Certificate Selection

63. One IP, Multiple Certificates

70. Your `fullchain.pem`

71. Your `privkey.pem`

X.509 Certificates — The Exact Science Behind `fullchain.pem`