Encryption, Encoding and Hashes, and public keys.

Encryption, Encoding and Hashes, and public keys.

By ghost | 8957 Reads |

0     0

I've noticed that there's a lot of interest out there right now in encryption, and rightfully so. It seems that strong encryption will play an increasingly large role in the future of computer security.

Unfortunately, I've also noticed a fair bit of confusion. My goal in this article is to clear that up, and provide a starting point for those of us interested in the field.

Encoding,Encryption, and Hashes. Although you'll often see these terms used interchangably, it is important to understand the differences. We'll begin with the most common, encryption.

Encryption: Encryption is a process where a plaintext (a message) and a key (a secret password) are put through a REVERSABLE process (an algorithm) that produces corresponding ciphertext (looks like gibberish). A important point is that the process is reversable, meaning that anybody with the key, ciphertext and algorithm can produce the plaintext. Encrypting the same message with every possible key should produce as many different ciphertexts. Encrypting all possible messages with the same key should produce as many different ciphertexts as well.

Encoding: Encoding is a little like encryption, the only thing missing is the key. In encoding, a plaintext is put through an algorithm, which produces and encoded message. There is one and only one ciphertext for each plaintext. A good example of encoding is base64 encoding, or binary encoding of decimal numbers. Mp3 encoding is a way of encoding audio sound as bits and bytes. Your mp3 player decodes it, and feeds the sound to your speakers. In regards to security, encoding is the least significant of the three.

Hash: Hashes are perhaps the most misunderstood of all three. A hash is an algorithm that turns a plaintext into a corresponding hash. The same plaintext, hashed the same way will produce the same hash. In a secure hash, no different plaintexts will produce the same hash, and there will be no way to reverse the hash (ie. turn the hash back into plaintext) WITH or WITHOUT the algorithm.

"Wait a minute…" I can hear you say. "You said that hashes are non reversable. But the md5 hash is used for passwords all the time. How do programs know you have the right password. You even released an md5 hash cracker to the code bank DC." You're absolutely right, and so am I. You see. when you login to something that uses the md5 hash for it's password file, it's not reading the password from the file and comparing it to what you entered. Instead it will produce a hash of whatever you say the password is, and compare it to the hash of the correct password. Since the same word will always produce the same hash, and since no other word will produce the same hash, you can be sure that the passwords match if the hashes do too. Brute force hash crackers work by hashing every possible word until the hash matches the one you're trying to crack.

Public Key Encryption: Public key encryption deals with very large prime numbers and other math that is.. well… way over my head, but I'll touch on it here just because it's so important. Using regular (symetrical) encryption, if Alice wanted to talk secretly with Charles in a public forum, she and Charles would have to agree on a key and encryption algorithm in secret. But if Alice and Charles need encryption to talk in secret, how could they secretly communicate the key they'll use for encryption. This was called encryptions catch-22. In order to use encryption to secure a channel, you needed a secure channel to communicate the key. But if you already have a secure channel, why do you need encryption? Public key encryption is an ingenious invention that solves this conundrum. Under public key (asymetrical) encryption, every user has a public key (which everybody knows) and a private key (which only they know). There's a mathematical relationship between the two numbers that's way beyond this article. For Alice to send a message to Charles using public encryption, she would encrypt the message using her private key and Charles's public key. Because of the relationship between public and private keys, Charles could then decrypt that message using HIS private key and Alice's public one. Since anyone can know the public key, and nobody needs to know anybody's private key but their own, Alice and Charles can communicate privately without first needing to privately communicate an encryption key.

Further reading: http://www.faqs.org/faqs/cryptography-faq/ This humble documet offered to teach me more than I ever wanted to know about cryptology. It consists of 10 sections packed full of info.

That's it, that's all folks. I hope you enjoyed my little primer here. Don't worry if the math behind public key encryption seems arcane and unlikely. I think there are about 5 people in the world truely understand it. If anybody has any questions, feel free to PM me.