Get the Offline ArchiveFree lifetime updates

Encryption Basics

6 min read

Encryption protects data from anyone who can read the wire, using a shared secret key for the bulk of the data and a public and private key pair to agree on that key or to prove identity, which is how SSH and TLS work. Never design your own cipher: experienced professionals get it wrong, and the value of a published algorithm is that many people have tried for years and failed to break it. Use the working SSH and TLS software that salvaged machines already carry, guard the keys physically, and keep clocks right, because certificates carry expiry dates.

Part of Networking

Why and where to encrypt on a settlement network, the two kinds of key, and the rule of using published software rather than inventing any.

Encrypt Because The Wire Is Shared, And Use Only What Others Have Tried To Break

A settlement network is not secret by default. Network Interface explains that on a hub-based network a machine in capture mode sees all traffic on the segment, and on a switched network a mirror port or tap shows the same. Anyone who can plug into the cable, or reach a wireless access point, can read what is not encrypted. The carrier Internet Infrastructure says to encrypt sensitive communications even on a trusted community network: SSH for remote administration, never telnet, and TLS for web servers carrying sensitive content.

Do not design your own cipher, hash or protocol. This is the first rule and the most often broken. Designing an encryption scheme that survives attack is something that trained professionals get wrong; even the standard algorithms were published and attacked in public for years by many people trying to break them before anyone relied on them. A published, long-analysed algorithm is valuable for one reason: many people have attacked it and failed. A scheme you invent has been attacked by nobody, and it will feel secure to you for the same reason it feels secure to everyone who has ever invented one. A cipher that looks scrambled is not a cipher that is safe. Salvaged working software that implements the standard algorithms is enormously preferable to anything improvised, and nothing in this article describes how to build the algorithms themselves.

Two Kinds Of Key And What Each Is For

  • Symmetric — the same secret key encrypts and decrypts. It is fast and is used for the bulk of the data. The difficulty is getting the key to both ends without anyone else seeing it.
  • Asymmetric — a pair of keys: a public key that anyone may hold and a private key that stays with its owner. It lets two parties who have never met agree on a symmetric key, and lets an owner prove a message came from them. It is much slower, so it is used briefly at the start.
  • Hash — a one-way fingerprint of data, used to check integrity. File Transfer names SHA-256 as the current standard for verifying files and says MD5 is no longer considered secure for all purposes, a reminder that algorithms get retired.

A connection secured by TLS or SSH uses all three: asymmetric keys at the start to agree a symmetric key and to check identity, then the symmetric key for the data, with hashes checking that nothing was changed in transit (general knowledge, not from the other articles). Who vouches for a public key is a separate problem, and it is the subject of Certificate Authority.

What You Need

  • Software that already implements the standard protocols — SSH and a TLS library are on any Linux system, and the web and mail servers use them
  • A recent release if you have a choice — older software may offer obsolete algorithms by default, and no updates will arrive; turn off options its documentation marks as weak
  • Somewhere safe for private keys — a file with strict permissions, a passphrase, and a protected offline copy
  • A correct clock (Linux Server Setup)

Method: Encrypt In Order Of Value

Step 1: Remote administration over SSH, never telnet (carrier)

Step 2: File transfers over SSH SFTP, SCP or rsync over SSH, not plain FTP (File Transfer).

Step 3: Web logins and private pages over HTTPS Plain HTTP shows passwords to anyone listening (HTTP).

Step 4: Wireless networks with WPA2, or WPA3 if available, never WEP Network Hardware says WEP is broken.

Step 5: Protect the keys A private key that anyone can copy is worth nothing. Keep it readable only by the service that needs it, never email it, and replace keys when a person who held them leaves (Access Control).

Step 6: Keep the clocks right Certificates have validity periods (Resource Sharing makes the point about time).

Worked Example: Why Public Keys Scale

If every pair of people needs its own shared secret, a group of n people needs n(n-1)/2 of them. For n = 100 that is 100 x 99 / 2 = 4,950, the same count Messaging gives for communication pairs among 100 people. With public keys, each person has one pair, so 100 people need 100 pairs, and the public halves are shared openly. For n = 10 the figures are 45 secrets against 10 pairs. The saving grows with the group.

The clock: a certificate is valid between two dates. A machine that has lost its clock and restarts at a date years in the past will treat every certificate as not yet valid and refuse the connection, however correct the certificate is. The cure is setting the time, not replacing the certificate.

Common Mistakes

  • Inventing or “improving” an algorithm — it is untested, however clever it feels
  • Keeping a private key where others can read it — the key is the secret
  • Using an obsolete protocol because it still works — WEP, telnet and plain FTP all work, and all expose what they carry
  • Believing encryption fixes a stolen account — it protects the wire, not the password in a thief’s hand
  • Ignoring clocks — a wrong date looks like a broken certificate

What’s Next