The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

Symmetric Encryption, Asymmetric Encryption, and Hashing

By stretch | Tuesday, November 23, 2010 at 4:16 p.m. UTC

A fundamental topic of IT security that often gives people difficulty is understanding the difference between symmetric, asymmetric encryption, and hashing. While each has specific uses, a robust communications encryption solution will typically implement all three.

Symmetric Encryption

Symmetric encryption may also be referred to as shared key or shared secret encryption. In symmetric encryption, a single key is used both to encrypt and decrypt traffic.


Common symmetric encryption algorithms include DES, 3DES, AES, and RC4. 3DES and AES are commonly used in IPsec and other types of VPNs. RC4 has seen wide deployment on wireless networks as the base encryption used by WEP and WPA version 1.

Symmetric encryption algorithms can be extremely fast, and their relatively low complexity allows for easy implementation in hardware. However, they require that all hosts participating in the encryption have already been configured with the secret key through some external means.

Asymmetric Encryption

Asymmetric encryption is also known as public-key cryptography. Asymmetric encryption differs from symmetric encryption primarily in that two keys are used: one for encryption and one for decryption. The most common asymmetric encryption algorithm is RSA.

Compared to symmetric encryption, asymmetric encryption imposes a high computational burden, and tends to be much slower. Thus, it isn't typically employed to protect payload data. Instead, its major strength is its ability to establish a secure channel over a nonsecure medium (for example, the Internet). This is accomplished by the exchange of public keys, which can only be used to encrypt data. The complementary private key, which is never shared, is used to decrypt.


Robust encryption solutions such as IPsec implement the strengths of both symmetric and asymmetric encryption. First, two endpoints exchange public keys, which allows for the setup of a slow but secure channel. Then the two hosts decide on and exchange shared symmetric encryption keys to construct much faster symmetric encryption channels for data.


Finally, hashing is a form of cryptographic security which differs from encryption. Whereas encryption is a two step process used to first encrypt and then decrypt a message, hashing condenses a message into an irreversible fixed-length value, or hash. Two of the most common hashing algorithms seen in networking are MD5 and SHA-1.


Hashing is used only to verify data; the original message cannot be retrieved from a hash. When used to authenticate secure communications, a hash is typically the result of the original message plus a secret key. Hashing algorithms are also commonly used without a secret key simply for error checking. You can use the md5sum and sha1sum utilities on a Linux or Unix machine to experiment with hashing.

$ echo -n This is a secret message. | md5sum
39de572a4d05b1ad6552dcfee90f4d20  -
$ echo -n This is a secret message. | sha1sum
e35c5046b5fe69488ce0ab14c5761d785995ee79  -

Another example of MD5 hashing can be seen in IOS' secret passwords, which implement a random salt to avoid duplicate hashes should two users by chance select the same password.

Posted in Security

Support PacketLife by buying stuff you don't need!


November 23, 2010 at 5:40 p.m. UTC

Great explanation. Just keep in mind that sending a public key over an insecure channel opens one up to a man in the middle attack, which is why in SSL (and anyone else using an X.509 certificate), the key is signed by a mutually trusted third party.

Another interesting thing about public key cryptography is that the secret key can also be used to encrypt data and the public key can then decrypt it. That's how digital signatures work: Private key encrypts a hash of the message. If the private key decrypts it and calculates the same hash, the signature is validated.

Lawrence Teo
November 23, 2010 at 5:41 p.m. UTC

Great intro blog post on these three concepts!

Just a quick note: MD5 and SHA-1 are known to have vulnerabilities and their use should be discouraged.

November 23, 2010 at 6:04 p.m. UTC

Ok, what to use then?


November 23, 2010 at 6:05 p.m. UTC

Great write up, stretch. You always manage to make a complex topic seem simple.

November 23, 2010 at 8:29 p.m. UTC

Great explanation !! Helpfull for my CCNP Security

November 23, 2010 at 8:42 p.m. UTC


While MD5 has been demonstrated to be insecure in real-world scenarios, SHA-1 is mathematically insecure and a hash collision could hypothetically exist; however, the real world does not always follow theory. Show me a real-world scenario where someone has created a useful SHA-1 hash collision.

Until the NIST completes their SHA-3 competition (which won't be completed until 2012) we won't have anything better. The SHA-2 hashes (with digests ranging from 224 to 512 bits) simply aren't widely implemented.

November 24, 2010 at 8:19 a.m. UTC

Related to: "Robust encryption solutions such as IPsec implement the strengths of both symmetric and asymmetric encryption. First, two endpoints exchange public keys, which allows for the setup of a slow but secure channel."

As far as I know the first step in IPSec it's the Diffie Hellman key exchange used by endpoints to have a shared secret which is the symmetric encryption key, and inside this symmetric encryption tunnel the asymmetric encryption public keys will be exchanged.


sha1 hash
November 24, 2010 at 4:36 p.m. UTC

Excellent intro. MD5 is known to be collision prone; and sha 1 is known to be collision possible. But like you said, until NIST is done that's what we have.

November 24, 2010 at 6:39 p.m. UTC


I've understood the key exchange in IPsec the same way, but would like confirmation on the subject. Would be nice if stretch would make an blog post of the IPsec key exchange.

IKE Phase 1 - Diffie-Hellman key exchange

IKE Phase 2 - Inside the DH symmetric encryption a change of public keys (X.509 certificates) which are then checked against a CA certificate (or just PSK)

IPsec - After the authentication between hosts a symmetric key is agreed upon per data direction. 2 symmetric keys for full duplex...

...correct me if i'm wrong...

November 25, 2010 at 12:20 p.m. UTC

@Addie You got a point :)

November 25, 2010 at 5:25 p.m. UTC

Yeah an article on IPsec VPNs and how they are set up would be wonderful. I've researched them and there isn't much out there that breaks it down into a step by step tutorial.

Anyone know of any out there?

Great article again by the way :-)

November 29, 2010 at 6:12 a.m. UTC

Well done! Now, the clouds are disappeared!

November 29, 2010 at 11:32 a.m. UTC

Great article.

Remember, as well as MD5 having a higher collision rate, it should never be used as the actual algorithm has been compromised for some time now (see below for a hash decrypter, generate an MD5 hash else where and then decrypt).

Only ever should SHA be used for authentication such as VPN's.



November 29, 2010 at 8:15 p.m. UTC

I fortunately became ActivIdentity CMS 3.8 certified a few years ago in a previous job role for the implementation of a new smartcard system for the Depart of Work and Pensions in the UK which taught me a lot about PKI and encryption in general... really stoked my interest in it and probably one of the main reasons I would like to end up in a Network Security role.

December 1, 2010 at 7:26 a.m. UTC

Great intro blog post on these three concepts!

Vincent RABAH
December 2, 2010 at 9:53 p.m. UTC


A great explaination ! I have found a nice video the learn Key Exchange for children, have a look to my blog :

The post is writen in French but the video is in English ;)

Regards ... I really enjoy reading packetlife ;)

December 6, 2010 at 1:17 a.m. UTC

@quantumbit: That "decryption" website you gave actually only looks up the hash in its database, it does not (as far as I can tell anyway) perform any actual "decryption" (which is an incorrect term, "dehashing" would be more appropriate).

January 4, 2011 at 6:46 a.m. UTC


The DH-exchange uses asymmetric encryption to create a secure "channel," not tunnel; as a tunnel implies an additional encapsulation at the same layer. The DH-keys are then used to generate/agree on the symmetric keys used for data encryption in the IPsec tunnel. During (IKE Phase 1/ISAKMP), the DH aysmmetric keys are used to encrypt the peer authentication packets and IPsec transform sets.

June 21, 2012 at 4:33 a.m. UTC

Thanks for Sharing the Nice Tool! I know one more site:

June 10, 2013 at 7:04 a.m. UTC

is hashing already implemented in encryption?is there any additional use of hash generation?

December 11, 2014 at 5:47 a.m. UTC

Good Article

September 12, 2016 at 1:23 a.m. UTC

Thank you!

Comments have closed for this article due to its age.