How Public-Key Cryptography Works — LearningTechBasics

LT LearningTechBasics @amtocbot

How Public-Key Cryptography Works

One key locks, a different key unlocks — and that changes everything.

📅 2026-07-24⏱️ ~6 min read🏷️ Security · Cryptography

Symmetric encryption needs both sides to already share a secret. Public-key crypto breaks that chicken-and-egg problem with a mathematically linked key pair — one you publish, one you keep.

A

🔓

Public key

B

🔑

Private key

1Encrypt with public

2Only private decrypts

3Sign with private

4Anyone verifies with public

Legend — how to read this diagram

A · BPartiesthe two sides of the exchange

1–nOrdereach message, numbered in sequence

1 2 3Walkthroughnumbered steps below run in order

Two superpowers

1. Encryption. Anyone encrypts a message with your public key; only your private key can open it.
2. Signatures. You sign with your private key; anyone verifies with your public key that it was really you.
3. Key exchange. Two parties can derive a shared secret over an open channel (Diffie–Hellman).
4. Trust. Certificates bind a public key to an identity, vouched for by a signature.

Why it's hard to break

Trapdoor functions. Easy one way (multiplying primes), infeasible the other (factoring the product).

Key size vs. speed. RSA needs big keys; elliptic-curve crypto gets the same strength with far smaller ones.

Slow by design. Used to bootstrap a fast symmetric key, not to encrypt bulk data directly.

One-line mental model:

Separate the ability to lock from the ability to unlock, and strangers can exchange secrets in the open.

Made by LearningTechBasics · @amtocbot · One tech idea, clearly explained · #LearningTechBasics

How CPU Caches Work — LearningTechBasics

LT LearningTechBasics @amtocbot

How CPU Caches Work

Why the same loop can run 10× faster depending on memory order.

📅 2026-07-23⏱️ ~6 min read🏷️ Systems · Performance

Your CPU is far faster than your RAM. Caches — small, fast memories close to the core — bridge the gap by keeping recently and soon-to-be-used data nearby.

ACPU registers · <1ns

BL1 cache · ~1ns

CL2 cache · ~4ns

DL3 cache · ~15ns

EMain RAM · ~100ns

Legend — how to read this diagram

A–EComponentsthe parts involved, labelled in the diagram

1 2 3Walkthroughnumbered steps below run in order

The memory hierarchy

1. Registers. A few dozen slots inside the core, accessed in a single cycle.
2. L1/L2. Per-core caches, kilobytes to a megabyte, a handful of nanoseconds away.
3. L3. Shared across cores, several megabytes, slower but still far faster than RAM.
4. RAM. Gigabytes, but ~100× slower than L1 — a cache miss stalls the core.

Writing cache-friendly code

Locality wins. Data fetched in 64-byte cache lines; touching neighbors is nearly free.

Iterate in memory order. Row-major arrays should be traversed row by row, not column by column.

Compact structures. Smaller, contiguous data fits more per line and misses less often.

One-line mental model:

Speed isn't just how many operations you do — it's how far the data had to travel to reach the core.

Made by LearningTechBasics · @amtocbot · One tech idea, clearly explained · #LearningTechBasics

How Git Stores Your History — LearningTechBasics

LT LearningTechBasics @amtocbot

How Git Stores Your History

Not diffs — a tree of snapshots addressed by their own hash.

📅 2026-07-23⏱️ ~6 min read🏷️ Tools · Version Control

Most people picture Git storing the changes between versions. It actually stores full snapshots, each addressed by a SHA hash, linked into a chain — which is why it's so fast and so hard to corrupt.

0commit C3

1commit C2

2treeblob ablob b

Legend — how to read this diagram

0–nDepthlevels from the root downward

1 2 3Walkthroughnumbered steps below run in order

The four objects

1. Blob. The raw contents of a file. Identical files anywhere share one blob.
2. Tree. A directory listing: names pointing to blobs and other trees.
3. Commit. A snapshot: a pointer to one tree, parent commit(s), author, and message.
4. Tag. A named pointer to a specific object, usually a release.

Why hashing everything matters

Content addressing. An object's name is the hash of its content, so identical content is stored once and corruption is detectable.

Cheap branches. A branch is just a 40-character pointer to a commit — creating one writes a tiny file.

Integrity. Each commit's hash includes its parent's, so history can't be altered without changing every hash after it.

One-line mental model:

Git is a content-addressed filesystem: name everything by its hash, and history becomes a tamper-evident chain of snapshots.

Made by LearningTechBasics · @amtocbot · One tech idea, clearly explained · #LearningTechBasics

How Hash Tables Work — LearningTechBasics

LT LearningTechBasics @amtocbot

How Hash Tables Work

Average O(1) lookups — the data structure hiding behind every dictionary.

📅 2026-07-22⏱️ ~5 min read🏷️ Data Structures · Fundamentals

A hash table stores key-value pairs and finds any of them in roughly constant time. The trick: a hash function turns a key into an array index directly, skipping the search entirely.

key → hash → bucket

Legend — how to read this diagram

▮Activehighlighted cell is currently selected

1 2 3Walkthroughnumbered steps below run in order

How a lookup works

1. Hash the key. A hash function maps the key to a big integer, spread as evenly as possible.
2. Modulo the size. That integer mod the array length gives a bucket index.
3. Store or fetch. The value lives in that bucket. To read, hash again and jump straight there.
4. Handle collisions. Two keys can land in the same bucket; chaining (a list per bucket) or open addressing resolves it.

The trade-offs

Load factor. When the table gets ~70% full, it resizes and rehashes to keep collisions rare.

Worst case O(n). A bad hash (or adversarial keys) can pile everything into one bucket.

No ordering. Iteration order is arbitrary — use a tree map if you need sorted keys.

One-line mental model:

Don't search for the key — compute exactly where it must live.

Made by LearningTechBasics · @amtocbot · One tech idea, clearly explained · #LearningTechBasics

How the TCP Handshake Works — LearningTechBasics

LT LearningTechBasics @amtocbot

How the TCP Handshake Works

SYN, SYN-ACK, ACK — the three words that start every reliable connection.

📅 2026-07-22⏱️ ~5 min read🏷️ Networking · Fundamentals

TCP turns the internet's unreliable packet delivery into an ordered, lossless stream. Before any data flows, both sides synchronize sequence numbers in a three-way handshake.

A

💻

Client

B

🖥️

Server

1SYN seq=x

2SYN-ACK seq=y ack=x+1

3ACK ack=y+1

4Connection established

Legend — how to read this diagram

A · BPartiesthe two sides of the exchange

1–nOrdereach message, numbered in sequence

1 2 3Walkthroughnumbered steps below run in order

Three-way handshake

1. SYN. The client picks a random sequence number x and sends a SYN packet to open the connection.
2. SYN-ACK. The server picks its own y, acknowledges x+1, and sends both back.
3. ACK. The client acknowledges y+1. Both sides now agree on starting sequence numbers.
4. Data flows. Every byte is numbered; the receiver ACKs what it got so losses can be retransmitted.

What sequence numbers buy you

Ordering. Packets can arrive out of order; sequence numbers let the receiver reassemble the stream correctly.

Reliability. Unacknowledged bytes are resent after a timeout.

Flow & congestion control. Windows tell the sender how much to send before waiting, adapting to the network.

One-line mental model:

Agree on where counting starts, number every byte, and acknowledge what arrives — that's how an unreliable network becomes a reliable pipe.

Made by LearningTechBasics · @amtocbot · One tech idea, clearly explained · #LearningTechBasics

How HTTPS & TLS Work — LearningTechBasics

LT LearningTechBasics @amtocbot

How HTTPS & TLS Work

How two strangers agree on a secret nobody else can read.

📅 2026-07-21⏱️ ~6 min read🏷️ Security · Networking

HTTPS is HTTP running inside a TLS tunnel. TLS lets a browser and a server that have never met agree on a shared encryption key over an open, hostile network — and prove the server is who it claims to be.

A

🧑‍💻

Client

B

🖥️

Server

1ClientHello + ciphers

2ServerHello + certificate

3Verify cert · key exchange

4Finished · encrypted tunnel

Legend — how to read this diagram

A · BPartiesthe two sides of the exchange

1–nOrdereach message, numbered in sequence

1 2 3Walkthroughnumbered steps below run in order

The handshake

1. ClientHello. The browser lists the TLS versions and cipher suites it supports, plus a random number.
2. ServerHello + certificate. The server picks a cipher and sends its certificate, signed by a trusted Certificate Authority.
3. Verify. The browser checks the certificate chains up to a CA it trusts and matches the domain.
4. Key exchange. Using ECDHE, both sides derive the same session key without ever sending it across the wire.
5. Finished. Both send a MAC over the whole handshake. From here, everything is symmetrically encrypted.

Why it's secure

Asymmetric to bootstrap, symmetric to run. Public-key crypto is slow, so it's used only to agree on a fast symmetric key.

Forward secrecy. Ephemeral keys (ECDHE) mean stealing the server's private key later can't decrypt old traffic.

Trust anchors. Your device ships with ~150 trusted CAs; the whole system rests on their signatures.

One-line mental model:

Use expensive public-key math once to agree on a cheap shared secret, prove identity with a signed certificate, then encrypt everything.

Made by LearningTechBasics · @amtocbot · One tech idea, clearly explained · #LearningTechBasics

How DNS Works — LearningTechBasics

LT LearningTechBasics @amtocbot

How DNS Works

The internet's address book — turning a name into an IP in milliseconds.

📅 2026-07-21⏱️ ~5 min read🏷️ Networking · Fundamentals

Every time you visit a website, your device must translate a human-friendly name into a machine address. That translation is the job of the Domain Name System — a globally distributed, hierarchical database.

A

💻

Your devicestub resolver

B

🗂️

Recursive resolverISP / 1.1.1.1

C

🌐

Root & TLD. → .com

D

🏠

Authoritativeholds the record

Legend — how to read this diagram

A–DComponentsthe parts involved, labelled in the diagram

●Requestdata travelling outward

●Responsedata returning

1 2 3Walkthroughnumbered steps below run in order

The journey, step by step

1. Cache check. Your OS and browser first check their own caches. A recent hit resolves in microseconds — no network needed.
2. Ask the recursive resolver. On a miss, your device asks a recursive resolver (your ISP's, or a public one like 1.1.1.1). It does the legwork.
3. Root servers. The resolver asks a root server: who handles .com? It replies with the .com TLD servers.
4. TLD servers. The resolver asks the .com server who is authoritative for the domain, and gets the authoritative name server.
5. Authoritative answer. That server returns the real A record (IPv4) or AAAA record (IPv6), e.g. 93.184.216.34.
6. Cache & connect. The resolver caches the answer for its TTL and your browser opens a connection to that IP.

Why it's built this way

Hierarchy = scale. No single machine could hold every domain. Splitting responsibility means each layer only knows who to ask next.

Caching = speed. TTLs let answers live near you, so most lookups never leave your resolver.

Record types matter. A/AAAA for addresses, CNAME for aliases, MX for mail, NS for delegation.

One-line mental model:

DNS is a chain of 'I don't know, but ask them' — until someone says 'here's the address,' and everyone remembers it for a while.

Made by LearningTechBasics · @amtocbot · One tech idea, clearly explained · #LearningTechBasics