Encryption and digital signatures, the basics

A long-standing rule in the field, known as Kerckhoffs's principle, says a system should stay secure even if everything about it is public except the key. In practice this means the method is published and examined by many experts, and only the key is secret. Secret, home-made methods ("security through obscurity") have a poor record, because the people who most need to examine them never get the chance.

Hiding data is not enough: an attacker who cannot read a message might still change it. Modern designs therefore use authenticated encryption, which both hides the data and attaches a check so that any tampering is detected when the message is opened. This is one more reason to use a well-tested library mode and not assemble pieces by hand: the order and combination of the pieces matters, and mistakes are easy to make and hard to see.

Public-key methods rest on mathematical problems believed to be hard to reverse, and they are much slower than symmetric methods. So they are typically used for small jobs: agreeing on a shared key, or protecting a short key, and for signatures. Standards in this area evolve, including work on methods designed for a future where much larger computers might exist. Follow current guidance from a trusted standards body and do not rely on summaries like this one for choices.

In outline, the signer computes a hash of the message and uses the private key to produce a signature over it. A verifier recomputes the hash and uses the public key to check the signature. Two properties follow: authenticity (it was made by the holder of the private key) and integrity (the message has not changed since signing). A signature does not hide the message, since signing and encrypting are separate operations, and it only proves that the key was used, not that the key's owner is who you assume. That last gap is why certificates exist.

Some key agreement methods use fresh, temporary values for each connection. The benefit, called forward secrecy, is that if a long-term key is stolen later, old recorded conversations still cannot be unlocked with it. Current standards for secure connections favour designs with this property.

Authorities can sign certificates for other authorities, forming a chain from the site up to a trusted root. A certificate is checked for a valid signature, a matching name and whether it has expired or been revoked. The weakness is human and organisational: you are trusting the authorities, so the system's safety depends on their care and on the software's checks.

In most real incidents the mathematics held and the handling failed: keys were left in code repositories, shared by email, never rotated or kept next to the data they protected. Good practice means generating keys with trusted tools, storing them in purpose-built secret stores or hardware, limiting who can use them, rotating them, and planning for loss. Treat key handling as the main design problem, not an afterthought.

Encryption protects data from people who cannot get the key. It does not hide the fact that a conversation happened, it does not help when an attacker controls the device that holds the decrypted data, and it does not fix tricking a person into giving access away. Security is a chain of such links, and a strong cipher is only one of them.