Encryption Algorithm
Image: Stern, Public domain, Wikimedia Commons
In short: The concrete mathematical procedure by which plaintext is converted into ciphertext using a key (and back again).
In more detail: Well-known symmetric algorithms are AES (current standard) and the outdated DES/3DES. Among asymmetric schemes, RSA and elliptic curves (ECC) are common. Important: the security of a scheme doesn’t depend on the algorithm staying secret (security by obscurity is considered bad practice) — modern algorithms are publicly documented and have been reviewed by the cryptography community. What has to stay secret instead is the key.
In Depth
The principle “security by obscurity is bad” (also known as Kerckhoffs’s principle, formulated in 1883) sounds counterintuitive at first — why would you make your own encryption algorithm public? The reasoning: an algorithm that has to stay secret to be secure is inherently fragile — as soon as it ever leaks (reverse engineering, an insider, a leak), all security is instantly and completely lost. A public algorithm reviewed by thousands of cryptographers worldwide, like AES, is by contrast much more robust, because it doesn’t rely on secrecy of the method, but solely on secrecy of the key:
Bad: Security = secret algorithm + secret key
(algorithm leaked -> everything compromised)
Correct: Security = public, reviewed algorithm + secret key
(algorithm is publicly known -> only losing the key is critical)
The algorithms considered secure today all have one thing in common: they went through an open, often years-long selection process with public review by the international cryptography community — AES, for example, was chosen in 1997–2000 in an open NIST competition among several submitted candidates, precisely BECAUSE it could be publicly checked for weaknesses. Self-built, “secret” encryption schemes from individual companies or developers are considered a warning sign in the cryptography community, not a security benefit — without public review by experts, it’s practically never possible to rule out that a homegrown scheme has serious, undiscovered weaknesses.
How an algorithm officially becomes a standard
The path from a newly proposed algorithm to a recognised standard like AES is deliberately lengthy and public: for the AES selection, research teams worldwide submitted 15 different candidate algorithms, which were then publicly examined for weaknesses by the entire cryptography community over several years — anyone was allowed to try to break a candidate, and the results openly fed into the evaluation. Only after an algorithm survives this process unscathed for years is it considered trustworthy enough for widespread practical use. A current example of this process is happening right now with “post-quantum cryptography”: NIST has been standardising new algorithms for several years that are meant to remain secure even against future quantum computers, again through a multi-year, public selection process with contributions from research groups worldwide.
The difference between algorithm and implementation
An often-overlooked point: even a mathematically perfectly secure algorithm can become insecure through a flawed concrete implementation. The Heartbleed bug (2014) in the widely used OpenSSL library wasn’t a flaw in the TLS algorithm itself, but a simple programming error in its implementation that allowed attackers to read arbitrary memory contents of the server — including private keys and user passwords. This shows: alongside choosing a reviewed algorithm, choosing a reviewed, up-to-date implementation is also crucial — self-written cryptographic libraries are considered even riskier in practice than homegrown algorithms, because implementation bugs (memory access errors, incorrect random number generation, side-channel leaks) are at least as common as theoretical weaknesses in the algorithm itself.
See also: Encryption, Hashing