Hash Decryption
I was reading an earlier thread about hashing functions being decrypted and just now reading about assymetric encryption from a security+ prep guide that I bought. (WILEY) I had a thought, I believe that somewhere in my studying I have heard that Hashing is one way and cannot be decrypted, BUT isn't assymetric encryption a ONE WAY encryption process that uses hashing algorithms. Then with the correct key that information is decrypted.
The terminology is quite confusing, I understand Public Key Encryption, and I think I basically understand hashing, but I am quite confused.
The terminology is quite confusing, I understand Public Key Encryption, and I think I basically understand hashing, but I am quite confused.
Comments
Symmetric vs asymmetric is simply whether you use the same key (like a shared secret for instance) or different key (as in PKI) in the encryption process. Hashing may use what's called a "one-way" hash because it is difficult to reverse engineer or invert the procedure used to create the hash.
Clear as mud, right?
Yes, that is a fair enough statement. Symmetric encryption schemes only provide confidentiality, they have very little in the way of authentication and nonrepudiation.
Free Microsoft Training: Microsoft Learn
Free PowerShell Resources: Top PowerShell Blogs
Free DevOps/Azure Resources: Visual Studio Dev Essentials
Let it never be said that I didn't do the very least I could do.
If that is the earlier thread you are refering to, then I suggest reading it again and focussing only on my and sprkymrk's replies. The hash value is the result of the one way encryption, the hash value does not 'contain' encrypted data. The data itself isn't encrypted.
No, symmetric, asymmetric, and hashing are three different types of cryptography. But, they are often implemented in combination in a protocol/system/product. For example, a hash value can be encrypted using asymmetric encryption, but an asymmetric key (public key for example) can be hashed as well.
A quick example for all three type of encryption:
Bob wants to send a message to Alice.
Bob doesn't want anyone to be able to intercept the message and read the text in the message, in other words, the text is confidential. Bob uses symmetric encryption to encrypt the message. To be able to encrypt the message, Bob will need a symmetric encryption algorithm or cipher such as DES and a key. But for Alice to be able to decrypt the message, she also needs the key.
Sending the key together with the message is of course not a good idea. So Bob needs a different, more secure way to send the key to Alice. Bob could choose one of the following two options:
Bob can use asymmetric 'instead' of symmetric encryption. This means Bob has a private key and Alice has Bob's public key (received from Bob in a certificate). The problem with this option is that asymmetric encryption is slow. Symmetric encryption is thousands of times faster.
Bob's second option is a faster one. He can use asymmetric encryption to send the symmetric key to Alice. This means Bob uses a key and fast symmetric encryption to encrypt the data, and then uses his private (asymmetric) key to encrypt the symmetric key. Alice uses Bob's public key to decrypt the symmetric key, which in turn is used to decrypt the data. In addition to confidentiality, this provides autentication (Alice knows it's Bob who send the message because she can only decrypt it with Bob's public key) and non-repudiation (Alice can prove Bob sent the message, because she can only decrypt it with Bob's public key).
(computer hardware and software generate the keys and take care of the work...)
The above may seem a pretty secure, but there's one thing missing, and that's 'integrity'. Even though Alice may receive the message and the symmetric key (and a digital certificate), she can't be certain that all those are real and not tampered with before they reached her computer. That's what hashing is used for: integrity. Alice receive a certificate from Bob (with Bob's public key), Alice needs to know if the information in the certificate is real.
When the CA (Certification Authority) issued the certificate to Bob, it used a hashing alghorithm on the information in the certificate. The name, public key, validity date etc. This produced a hash value. This value is included in the certificate. When Alice receives the certificate, she can use the same hashing algorithm on the certificate, and check if the resulting hash value is the same as the one in the certificate. If it is, Alice can assume that the certificate is authentic and hasn't been changed by a malicious individual.
SSL is also a good example of this hybrid approach:
You can read more about it in several of my Security+ TechNotes, but the one about email security covers a good part of it:
And as I mentioned in that earlier thread, try out this sample application I wrote:
www.techexams.net/Cryptotool_1_0_0_2.zip
We went over this before in the previous thread. No, you can not 'decrypt a hashed message'. The message itself doesn't change after hashing it, and the hash value does 'not' contain the message. There isn't any data in the hash and there is no 'encrypted' message, so there's nothing to decrypt either.
@Mark: have you been practicing fast-typing
I probably started 10 minutes before you did and only wrote 2 sentences compared to your short essay.
I think people find it hard to understand that encryption deals mainly with privacy, while hashing deals mainly with integrity. They work in combination with each other, but are two different things that each have a distinct function.
The key point to note is that the hash is a means of providing a level of assurance concerning integrity, not confidentiality of the text/message/data. Confidentiality is provided by the public key which encrypts, and the private key to decrypts. This is why anyone can theoretically send you a confidential message, without you having to give up your private key in order for them to do this. And this is why you see people posting their public keys on their websites and other public places. For example you might see "To send me a confidential message, use the public key below. It should be understood that if Johan sends me a private message using my public key, then I am the only one who's able to decrypt and read the message. Not even he can decrypt the message (even though he sent it). For me to send him a confidential message, I can't simply use my private key to encrypt it, then send it to him and expect that he can use my public key to decrypt. While this would theoretically work, it really provides me nothing, since my public key is public, anyone who has it can then decrypt my messages. I would have to use Johan's public key to encrypt my message to him, and then he would do the reciprocal of what I did when he sent me a message; he would use HIS private key to decrypt it. The fact of the matter is, the private key is not actually sent "packaged" inside the public key, it's just mathematically linked to it.
Keep this in mind; In a public-key cryptosystem, the private key is always linked mathematically to the public key. Therefore, it is always possible to attack a public-key system by deriving the private key from the public key. Typically, the defense against this is to make the problem of deriving the private key from the public key as difficult as possible. For example, make it so that deriving the private key from the public key requires the attacker to factor large numbers, in this case it is computationally infeasible to perform the derivation. Who the heck knows what's going to happen with processing power over the next 5 to 10 years, so I always use the term infeasible, instead of impossible.
Part of the problem with understanding this all is that fact that you have very big name companies out there implementing this and not fully understanding it, then trying to explain to customers/clients and getting it all wrong. The end result is poor explanations and cloudy understanding across the board.
Also, I forgot to mention that the process of encasing a private key inside a public one, is a common technique, but when this is implemented it is usually for a communication session. In other words, that private key only lasts for that session. Which is why the private key, used in that context is actually known as a "session" key.
Now that is a great explanation. I wish one of the many Security+ books out there would have explained it that way. Excellent!