Blog Home > Authentication Security > Encryption Methods of Yesterday and their Replacements

Encryption Methods of Yesterday and their Replacements

| 1 Comment

encryption methodsEncryption methods are a very important aspect of security in our increasingly digital lives; and as a precocious, Chicago-based teen once opined in a John Hughes film, “Life moves pretty fast.” This sage observation is fitting for the computer industry as well, where cryptographic algorithms come with increasingly shortened half-lives due to hackers and academics attempting to “break” them for wholly different goals. In this context, “breaking” an algorithm refers to it becoming insecure or obsolete due to increased computing power, new attack vectors or previously undiscovered flaws in the algorithm itself. When one is broken, word quickly spreads, its plot in the computing graveyard is reserved and its successor comes out of the batters back and takes the plate. Today, I’m going to talk about a few encryption methods, which are out of date and which have taken up position at the forefront of digital cryptology.  

Categories of Cryptography

Let’s start with the two main types of cryptography:

  • Reversible

The originally encrypted data is retrievable if you have the algorithm, appropriate key and the encrypted data itself (i.e. cipher text). The cipher text length increases as the length of the original clear text increases. This classification includes both symmetric algorithms where the same key is used to both encrypt and decrypt information, and asymmetric algorithms where a pair of keys are involved – operations using one key (e.g. a public key) can only be reversed using a different key (e.g. the private key) and vice versa.

  • Irreversible

Regardless of the length of the input data, the cipher text is a fixed length. The original data is lost and verification is typically done by running the same clear text data through the same algorithm. Hashing algorithms fall into this category and good ones evenly distribute results and have no apparent correlation between the input and the resulting hash value.

Modern Ancients – Outdated Encryption Methods

The Ghosts of Christmas Past; each of these algorithms was the proverbial king of the hill at one time but have since been deprecated.

No…Not That King of the Hill (via GIPHY)

Reversible Encryption Methods

  • RC2/RC4

These symmetric key encryption algorithms were created by Ron Rivest back in the mid 80’s. You’ll know him as the “R” in “RSA”. It was successfully attacked by academics in the late 90’s. Some Microsoft products still support RC4 for backwards compatibility, but it is not recommended.

This symmetric key encryption algorithm stands for “Data Encryption Standard” and was recommended by NIST and the US government. 3DES uses a 168-bit key and was used in Microsoft’s Kerberos implementation up until Windows 7 and Windows 2008 Server. It is still considered cryptographically secure and is available for backwards compatibility, but there are now better alternatives that should be used in newer environments or projects.

Irreversible/Hashing Encryption Methods

  • MD2/MD4/MD5

This family of hashing algorithms was popular for many years, but researchers determined how to create “collisions” in 2004. Programs exist today (link) that can create executables with identical MD5 hashes but wildly different behaviors (an “evil twin”).

  • SHA-1

A relative newcomer to the algorithmic graveyard, no one other than Google has hastened its exit (link) by having its Google Chrome web browser treat SSL certificates using SHA-1 signatures as untrustworthy (no more nice, green lock). Citing similar attacks against MD5, Google has succeeded in leveraging its considerable browser market share to force more stringent security on the Web – kudos to them.

Modern Champions – Updated Encryption Methods

Now for the champions of the day! Strive to use these algorithms but be sure to employ well-exercised, publicly-available implementations.

Reversible Encryption

  • AES

This stands for “Advanced Encryption Standard” and is the successor to DES as recommended by NIST. It’s prior name is Rijndael – just in case you run across it. It offers varying symmetric key sizes from 128 to 256-bit, but even 128-bit keys are currently considered “good” until 2031 (link). You can’t go wrong with this algorithm as your symmetric encryption method.

The standard-bearer when it comes to asymmetric (aka “public/private key”) encryption, RSA serves at the bedrock that provides for SSL tunnels and digital signatures. This algorithm was developed in the late 1970s and it took until 2010 to break a 768-bit key. The ability to use varying key lengths has prolonged the life of this algorithm and 2048 bits is considered secure today.

  • ECC

This is an acronym for “Elliptical Curve Cryptography” and it is a relative newcomer – having been recommended by NIST in 2005. A 256-bit ECC key is relatively the same strength as a 3072-bit RSA key, which should provide some comparison for expected life.


  • SHA-2

The progeny of SHA-1, this family of hashing algorithms was also recommended by NIST in 2005 and has result sizes ranging from 224 to 512 bits. The 256, 384 and 512-bit sizes are purported to be good for at least the next 5 years (link).

  • Key Derivation Functions

Worthy of a special mention, KDFs can take a user-provided password and apply an iterative cryptographic operation to it to arrive at a value that can then be used as a sufficiently complex encryption key. PBKDF2 and bcrypt/scrypt are worth your time if you’re looking for this sort of thing.

Although this piece does no justice to the mathematical marvels conjured by modern sorcerers, hopefully it can serve as a rudimentary waypost or sanity check. New vulnerabilities and attacks surface every day, so do your best to keep up to date with the latest news. We all know what Ferris says!


Please follow and like us:
Gregg Browinski

Author: Gregg Browinski

Gregg, PistolStar’s Chief Technology Officer, oversees PistolStar’s product development and technical support. Prior to joining the company in 2001, he received extensive experience as a developer at IBM Lotus and Iris Associates. Gregg has served as the lead architect and developer for PistolStar’s Password Power suite of authentication solutions. He is responsible for the product’s technical success and the recognition it has received through award nominations.

One Comment

  1. Hi thanks!! the information…

Leave a Reply

Required fields are marked *.

Main menu