I thought I should make a running post on cryptography ciphers (algorithms) and such. For instance, in my previous post I mentioned AES, EDH, etc. but that’s just the tip of the ice-berg as there are so many algorithms each suited for different tasks. As I come across these I’ll add them to this post as a quick reference to myself.

Symmetric key algorithms (Private key cryptography)

Both parties share a private key (kept secret between them).

Symmetric key algorithms are what you use for encryption. F0r example: encryption of traffic between a server and client, as well as encryption of data on a disk.

DES – Data Encryption Standard – designed at IBM

DES is a standard. The actual algorithm used is also called DES or sometimes DEA (Digital Encryption Algorithm).

DES is now considered insecure (mainly due to a small key size of 56-bits).

Triple DES (3DES) applies the DES algorithm thrice and thus has better practical security. It has 3 keys of 56-bits each (applied to each pass of DES/ DEA).

AES is based on the Rijndael cipher. There was a competition to choose the cipher that will become the AES. The Rijndael cipher won the competition. However, there are some differences between Rijndael and its implementation in AES.

AES-GCM (AES operating in Galois/Counter Mode (GCM)) is preferred (check this blog post too). It is fast and secure and works similar to stream ciphers. Can achieve high speeds on low hardware too. Only supported on TLS 1.2 and above.

AES-CBC is what older clients commonly use. AES-CBC mode is susceptible to attacks such as Lucky13 and BEAST.

Asymmetric key algorithms (Public key cryptography)

Each party has a private key (kept secret) and a public key (known to all). These are used in the following way:

Public keys are used for encrypting, Private keys are used for decrypting.

For example: to send something encrypted to a party use its public key and send the encrypted data. Since only that party has the corresponding private key, only that party can decrypt it. (No point encrypting it with your private key as anyone can then decrypt with your public key!)

Private keys are used for signing, Public keys are used for verifying.

For example: to digitally sign something, encrypt it with your private key (usually a hash is made and the hash encrypted). Anyone can decrypt this data (or decrypt the hash & data and perform a hash themselves to verify your hash and their hash match) and verify that since it was signed by your private key the data belongs to you.

These algorithms are usually used to digitally sign data and/ or exchange a secret key which can be used with a symmetric key algorithm to encrypt further data. They are often not used for encrypting the conversation either because they can’t (DSA, Diffie-Hellman) or because the yield is low and there are speed constraints (RSA). Most of these algorithms make use of hashing functions (see below) for internal purposes.

RSA – short for the surnames of its designers Ron Rivest, Adi Shamir and Leonard Adleman

Public and Private keys are based on two large prime numbers which must be kept secret. RSA’s security is based on the fact that factorization of large integers is difficult. (The public and private keys are large integers which are derived from the two large prime numbers).

PKCS#1 is a standard for implementing the RSA algorithm. The RSA algorithm can be attacked if certain criteria are met so the PKCS#1 defines things such that these criteria are not met. See this post for more info.

Was originally patented by the RSA but has since (circa 2000) expired.

Unlike RSA which makes a hash of the data and then encrypts it to sign the message – and this data plus encrypted hash is what’s used to verify the signature – DSA has a different process. DSA generates a digital signature composed of two 160-bit numbers directly from the private key and a hash of the data to be signed. The corresponding public key can be used to verify the signature. The verifying is slow.

A note about speed: DSA is faster at signing, slow at verifying. RSA is faster at verifying, slow at signing. The significance of this is different from what you may think. Signing can be used to sign data, it can also be used for authentication. For instance, when using SSH you sign some data with your private key and send to the server. The server verifies the signature and if it succeeds you are authenticated. In such a situation it doesn’t matter that DSA verification is slow because it usually happens on a powerful server. DSA signing, which happens on a relatively slower computer/ phone/ tablet is a much faster process and so less intensive on the processor. In such a scenario DSA is preferred! Remember: where the slow/ fast activity occurs also matters.

DSA can be used only for signing. So DSA has to use something like Diffie-Hellman to generate another key for encrypting the conversation.

This is a good thing as it allows for Perfect Forward Secrecy (PFS).

Forward Secrecy => the shared key used for encrypting conversation between two parties is not related to their public/ private key.

Perfect Forward Secrecy => in addition to the above, the shared keys are generated for each conversation and are independent of each other.

Section 3.9.1.2 of this article is worth a read. Since it’s designed by the NSA, DSA has some controversies.

SSH v2 can use RSA or DSA keys (for identity verification). It prefers DSA because RSA used to be patent protected. But now that the patents have expired RSA is supported.

RSA is supported by all versions of SSL/ TLS.

DSA (and ECDSA) requires random numbers. If the random number generator is weak then the private key can be figured out from the traffic. See this blog post and RFC for good explanations. These StackExchange answers are worth a read too: 1, 2, and 3.

ECDSA – Elliptic Curve DSA

Variant of DSA that uses Elliptic Curve Cryptography (ECC).

ECC is based on Elliptic Curves theory and solving the “Elliptic Curve Discrete Logarithm Problem (ECDLP)” problem which is considered very hard to break.

As with DSA it requires a good source of random numbers. If the source isn’t good then the private key can be leaked.

Although the ECDLP is hard to solve, there are many attacks that can successfully break ECC if the curve chosen in the implementation if poor. For good ECC security one must use SafeCurves. For example Curve25519 by D.J. Bernstein.

Used in Bitcoin and extensively in iOS for instance. Many web servers are adopting it too.

ElGamal – designed by Taher ElGamal

Used by GnuPG and recent versions of PGP

Taher ElGamal also designed the ElGamal signature, of which the DSA is a variant. ElGamal signature is not widely used but DSA is.

Does not do encryption or signing. It is only used for arriving at a shared key. Unlike RSA where a shared key is chosen by one of the parties and sent to the other via encryption, here the shared key is generated as part of the conversation – neither parties get to choose the key.

Here’s how it works in brief: (1) the two parties agree upon a large prime number and a smaller number in public, (2) each party then picks a secret number (the private key) for itself and calculates another number (the public key) based on this secret number, the prime number, and the smaller number, (3) the public keys are shared to each other and using each others public key, the prime number, and the small number, each party can calculate the (same) shared key. The beauty of the math involved in this algorithm is that even though a snooper knows the prime number, the small number, and the two public keys, it still cannot deduce the private keys or the shared key! The two parties publicly derive a shared key such that no one snooping on their conversation can derive the key themselves.

Has two versions:

a fixed/ static version (called “DH”) where all conversations use the same key,

an ephemeral version (called “EDH” (Ephermeral Diffie-Hellman) or “DHE” (Diffie-Hellman Ephemeral)) where every conversation has a different key.

Its security too is based on the discrete logarithm problem (like DSA).

SSHv2 uses DH as its key exchange protocol.

Hashing functions

Hashing functions take input data and return a value (called a hash or digest). The input and message digest have a one-to-one mapping, such that given an input you get a unique digest and even a small change to the input will result in a different digest. Hashes are one way functions – given an input you can easily create a digest, but given a digest it is practically impossible to generate the input that created it.

MD2 – Message-Digest 2 – designed by Ron Rivest

Is optimized for 8-bit computers. Creates a digest of 128-bits.

No longer considered secure but is still in use in Public Key Infrastructure (PKI) certificates but is being phased out?

MD4 – Message-Digest 4 – designed by Ron Rivest

Creates a digest of 128-bits.

It is used to create NTLM password hashes in Windows NT, XP, Vista, and 7.

MD4 is no longer recommended as there are attacks that can generate collisions (i.e. the same hash for different input).

MD5 – Message-Digest 5 – designed by Ron Rivest to replace MD4

As with MD4 it creates a digest of 128-bits.

MD5 too is no longer recommended as vulnerabilities have been found in it and actively exploited.

CER is a format for storing a single digital certificate (no private keys)

Base64-encoded or DER-encoded X.509 certificates.

SSL/ TLS are protocols that use the above

SSL – Secure Sockets Layer; TLS – Transport Layer Security

SSL has version 1.0 to 3.0. SSL version 3.1 became TLS 1.0. TLS has version 1.0 to 1.2. SSL and TLS are not interoperable (TLS 1.0 can have some of the newer features disabled, and hence security weakened, to make it interoperable with SSL 3.0)

Used for authentication and encryption. Makes use of the ciphers above.

Links

Since writing this post I came across some links related to the topics above. Thought I’d add them to this post in case anyone else finds these useful: