What Is Cryptography?

Cryptography is the discipline underneath almost every security control that actually works. It is also the area where organisations most reliably get into trouble by building rather than using — not because the mathematics is wrong, but because the implementation around it is where the failures live.

The practical rule is unchanged after decades: use well-reviewed implementations of standard algorithms, and spend your attention on key management, which is the part that genuinely goes wrong.

Three families, three jobs

Symmetric cryptography uses one key for both encryption and decryption. It is fast, suited to bulk data, and carries one hard problem: both parties need the key, and getting it to them securely is the entire difficulty.

Asymmetric cryptography uses a key pair, where one key encrypts and only the other decrypts. It solves the distribution problem and is slow, so in practice it is used to establish a shared symmetric key and to produce signatures rather than to encrypt bulk data.

Hashing is one-way: it produces a fixed-length digest that cannot be reversed. It answers integrity questions — has this changed — and, with the right construction, password storage.

Nearly every real protocol combines all three. A web session uses asymmetric cryptography to agree a key, symmetric to encrypt the traffic, and hashing to verify nothing was altered.

Key management is where it fails

The algorithms are not the weak point. Keys are: generated with insufficient entropy, stored next to the data they protect, shared across environments, embedded in source code, never rotated, and held by people who left two years ago.

A correctly chosen algorithm with a key in a configuration file committed to version control provides the appearance of protection and none of the substance. That is the most common cryptographic failure by a wide margin, and it has nothing to do with mathematics.

The rule about building your own

Do not implement cryptographic primitives. This is not conservatism — the failure modes are subtle, silent and not detectable by testing. Code that produces correct output can still leak the key through timing, reuse a value that must never repeat, or validate a signature in a way that accepts forgeries.

The same caution applies to composing primitives yourself. Choosing a mode of operation, constructing a protocol or deciding how to combine encryption with authentication are all places where correct-looking code is routinely broken. Use a vetted library at the highest level of abstraction it offers.

Inventory before migration

Every cryptographic change — a deprecated algorithm, a regulatory requirement, eventually post-quantum — begins with the same question: where is it used? Almost no organisation can answer, because cryptographic choices are scattered across application code, libraries, appliances, certificates and vendor products nobody wrote.

Building that inventory is unglamorous and it is the precondition for every future migration. Record which algorithms are used where, at what key length, who owns the system, and whether the choice can be changed by configuration or requires a code change. The systems in the last category are the ones that will define your migration timeline, and knowing which they are now is the difference between a planned programme and an emergency.

Where to start

Find out where your keys live and who can reach them. In most organisations that question has never been asked systematically, and the answer is more alarming than anything about the algorithms in use.

See encryption in practice and quantum computing threats. GuardsArm runs security risk assessments.