Difference Between Symmetric and Asymmetric

Difference between symmetric and asymmetric key cryptography?

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 decry-pt.

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. 

Hashing

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 - 

A bit more detail on IOS password hashes

It's no secret that the legacy "type 7" password hashes employed by older IOS devices are easily reversed. Wherever available, type 5 hashing is preferred as it generates a non-reversible MD5 hash. However, the one-way operation of MD5 isn't it's strongest benefit.


Recall that the generation of an MD5-type hash for a local user account is as simple as specifying secret instead of password:Router(config)# username foo secret MyP4ssw0rd Router(config)# do sh run | include username username foo secret 5 $1$jR5i$.HDBuKq.wIDOn2EYpCPYc0


Listed after the 5 in the above output is the resulting hash stored in the running configuration, but more than simple MD5 is at work here. Borrowed from the UNIX world, this method is referred to as a salted hash, its result composed of three elements separated by dollar signs ($):
1 - Denotes a salted hash
jR5i - 24-bit randomly generated salt value
.HDBuKq.wIDOn2EYpCPYc0 - MD5 hash

The salt and hash are binary data expressed in the configuration in Base64 encoding for readability. When the user foo needs to authenticate, the cleartext password provided by the human user is concatenated with the 24-bit salt stored in the configuration file. An MD5 hash is then generated from the entiresalt+password string; if the resulting hash matches the third element of the stored string, the provided password is deemed valid.

While this may seem unnecessarily complex, the implementation of salting provides two very sizable benefits. First, two users who happen to choose the same password will virtually always receive different hashes. Consider the addition of user bar who is assigned the same password as user foo from the previous example:Router(config)# username bar secret MyP4ssw0rd Router(config)# do sh run | include username username foo secret 5 $1$jR5i$.HDBuKq.wIDOn2EYpCPYc0 username bar secret 5 $1$P9XX$y9d6Aw.t81.CoKvXITCpZ/


Despite being able to authenticate with the same password, the two users were randomly assigned different salts at creation time, removing any similarity between their stored hashes.

The second, and arguably much stronger, benefit of this behavior is the crippling effect it has on space-time tradeoff cracking techniques like rainbow tables. The addition of a stored salt requires a hash to be pregenerated and stored not merely for each possible password (a very large number to begin with), but for every possible salt for every possible password. A 24-bit salt increases the resources required to generate such a hash database by 224, removing the appeal of such an attack venue.

For the curious, UNIX-like systems use the same hashing method for locally stored user accounts, though typically with a longer salt. In fact, the OpenSSL toolkit can be used to mimic the same operation performed by IOS device. By manually specifying the random salt generated by IOS for user foo, we can recreate the same MD5 hash on a separate computer:stretch@Sandbox$ openssl passwd -1 -salt jR5i MyP4ssw0rd $1$jR5i$.HDBuKq.wIDOn2EYpCPYc0