2016-09-24 21:10 by Ian
Intended audience and subject matter
This post is aimed at technical readers who may not be clear on the difference between symmetric and asymmetric cryptographic algorithms.
This post does not cover hash algorithms, despite the fact that they are essential to many cryptographic systems. They are not being discussed here because they are not reversible, and they have uses far beyond cryptography and security.
Nevertheless, their discussion in a cryptographic context is (at some point) essential to judging their properties and using them effectively. There is a separate post dedicated to there issues at this location.
Random number generators will also have an separate post.
The algorithms described here are all reversible, and all have cryptography or security as their primary applications.
Cryptography (particularly asymmetric key cryptography) is one of the domains of computer science where mathematical proficiency is *absolutely required* to design and evaluate the algorithms themselves. I will intentionally avoid deep discussion along those lines because there are people who are far better at it than I am, and anyone inclined to engage with such a post would be better-advised to learn from such a person. I will focus on implementation, and only dive into number-theoretic tangents when it is required to impart clarity to implementation choices.
Why those names?
The thing that makes a crypto algorithm (a)symmetrical is the balance of knowledge on either side of the operation. Symmetric algorithms require the same key material on both sides, and asymmetric does not. This is the only distinction.
This is what people generally think of when someone says "Encryption". These are the work-horses of bulk data obfuscation. Operations are generally referred to as "Encrypt" and "decrypt". Some people prefer "cipher/decipher", but the meaning is the same.
Encryption is carried out with a key of a given length (measured in bits). This key is mixed into the "plaintext" to produce a "ciphertext".
Decryption must be fed the ciphertext, and *the same **exact** key* that transformed the plaintext in the first place. Without that key, the data is no better than noise. In fact, re-purposing a symmetric algorithm into a pseudorandom number generator is trivial. This idea will be expounded in the PRNG post.
S-Box variants (AES, blowfish), Stream ciphers (Salsa20, A5/3).
Asymmetric (AKA, "Public key") cryptography
This class of algorithms underpins most (all?) certificates, and is the foundation upon which public-key infrastructure is built.
Asymmetric algorithms are typically used to establish authenticity and identity because the asymmetry of public and private keys creates a natural one-way relationship between signature and identity. Provided we have the public key, we can verify the signature of it's associated private key without being able to reproduce the signature ourselves.
Although "Encrypt/Decrypt" are appropriate descriptions of this family's operations, "Sign/verify" are often used to reflect the specific purpose of the encrypt/decrypt operations (which is almost never bulk data encryption). Some people prefer "validate" or "authenticate" instead of "verify". Again, the meanings are the same. Encryption is signing, and decryption is verification.
Asymmetric operations are generally *much* more expensive computationally. Moreover, many of them (RSA/ECC) risk leaking information about the signing (private) key if the message being signed becomes too long. For these reasons, the message is often hashed, and the *hash value* is the data that is encrypted (signed). The hash is discarded, and the signature is then appended to the message in some manner.
Authentication also computes the hash, but instead of encrypting the result with a private key, it decrypts the signature attached to the message with a public key (hence, the asymmetry) and compares the decrypted value with the hash it computed. If they match, the message is authentic.
RSA, Elliptic Curve, Diffie-Hallman.