encryption

bighornsheep · September 2006

I was having a discussion with a friend yesterday, and he tells me more or less the following:

anything that can be encrypted, can also be decrypted.

I somewhat disagree, because the decrypting process may take so long that it's basically not doable. He mentions that with hash functions, you can always come up with a return function that will decrypt information.

Is this true? My understanding of hash is that they are functions which are not 1-1, and it's impossible to know the transverse domain.

I know that this might be a vague topic, but with Computer Security in general, is this the correct (factual) mentality that any sort of prevention can be countered?

agustinchernitsky · September 2006

Well hash functions are one way... so, there is no decryption. Have you ever tried to decrypt a MD5 hash? LOL!

But with other types of encryption (symmetric / Asymmetric), with the given amount of computing power... yeah... you can decrtypt it.

seuss_ssues · September 2006

Anything that can be encrypted should be able to be decrypted otherwise what good is the encryption. You take your sensitive data and encrypt it so that no one not even yourself cannot decrypt it?

Im assuming you mean anything encrypted can be "cracked" then that also would be "true". Enough time and processor power and you can brute force virtually anything.

Slowhand · September 2006

In theory, what your friend says is true. If you were to run the exact same algorithm that the hash did, but in reverse, you'd be able to decrypte a hashed message. However, modern hashing algorithms generate a lot of random variables in order to achieve the kind of encryption we want, (as do other encryption methods, not just hashing). Basically, there's really no way of knowing what and MD5 hash, for example, used for variables in the encryption process, so it's very, very difficult to reverse-engineer that hash.

Just remember: security isn't about making information impossible to access. It's about making the chances of that information being compromised as improbable as possible. No encryption is perfect, no security method is, but some things are far, FAR too much trouble to try to break into. In most cases, even if you could decrypt a hashed piece of data, that data would probably be obsolete by the time you read it, (seeing as how you could be working on decrypting it for years on end.)

Webmaster · September 2006

No, there is no 'reverse' with hashing, it's one-way. More importantly, there is no encrypted data or message with hashing (SHA-1 or MD5 for example). There's just the message and the hash value (or message digest). It is impossible to 'decrypt the hash value/message digest' into something useful. For example, if you have a 650 MB download, and the publisher used a hasing algorithm to create a 32 bits hash value, and includes it with the download (so you can verify the integrity, see if the file hasn't changed during transmit), it's impossible to get the 650 MB of data out of the 32 bits MD5 digests, for example. This is the very reason this type of encryption exists: you don't have to encrypt/decyrpt the entire data 'just' for integrity.

Another simple example is the md5 hashing in Cisco devices for the 'enable secret' (basically the admin password). When you configure that password, md5 is used to create the message digest, which is then stored in the configuration. The password itself is not stored anywhere. When the user logs on, and types in the password, the device uses the same hashing algorithm on that password and then verifies if the outcome is the same as the hash value stored in the configuration. This is also why secure authentication use hashing algorithms, so they don't have to send anything over the line that could be decrypted into a password.

There are ways to crack hashing algorithms and defeat their purpose, but there's nothing to 'decrypt'.

Here's a simple MD5/SHA-1 utility I created for fun a while ago:

www.techexams.net/Cryptotool_1_0_0_2.zip

sprkymrk · September 2006

By definition, a one-way hash cannot be reversed, the "one way" means that it's nearly impossible to derive the original text from the string.

Here was a very scientific (to me anything that uses math is very scientific

) explanantion of such:
http://www.cs.bham.ac.uk/~mdr/teaching/modules04/security/lectures/hash.html

In part:

A one-way hash function H operates on an arbitrary length input message M, returning h=H(M). The important properties are:

Given M, easy to compute h=H(M)
Given h, hard to compute M such that h=H(M) -- "one-way"
Given M, hard to find M' (different from M) such that H(M)=H(M')
(Not always satisfied) Hard to find M,M' such that H(M)=H(M') -- "collision resistant"
Note that 4 implies 3 (i.e. if we could solve 3 we could solve 4), but not conversely. The strange thing about hash functions is that there are typically billions of collisions, or perhaps infinitely many (if the hash function really does take arbitrary-length input; most have some huge limit). But it is computationally hard to find a single one.

(Crud, webmaster beat me to the punch! Durn those fast typing programmers!

)

Slowhand · September 2006

I say we put the question before Deep Thought, and come back in about a million years, or so. Then we'll have an answer.

Webmaster · September 2006

Don't get me wrong but if it isn't rather obvious you can't recreate the data based on a message digest then you're not really understanding what a hashing algorithm is.

Apart from that, consider the simple math in the 650 x 32 bits exampe.

SHA-1 hash values for example, 160-bits. There's obviously a limit to the number of different SHA-1 hash values that you can create with 160 bits. (again this small size is so you don't need to actually encrypt the data). That allows for a lot of different possibilities, but not nearly as much as the unlimited different 'messages' (data) that can be hashed. It's impossible to create a different hash value for all different pieces of data that a user could create. That's why there are collisions. But that also proves that it is impossible to fits every possible 650 MB CD in one of those limited amount of available hash values. Logically, vice versa you cannot use those 160-bits to recreate and possible 650 MB CD.

It's breakable, ie. finding a collision, basically a brute force attacks, but that does not work because it decrypts a message digest but because it uses different data to reproduce the same message digest. The original data is still not known. Again, it's not encrypted, so it can't be decrypted either.

bighornsheep · September 2006

seuss_ssues wrote:

Anything that can be encrypted should be able to be decrypted otherwise what good is the encryption. You take your sensitive data and encrypt it so that no one not even yourself cannot decrypt it?

Im assuming you mean anything encrypted can be "cracked" then that also would be "true". Enough time and processor power and you can brute force virtually anything.

Slowhand wrote:

In theory, what your friend says is true. If you were to run the exact same algorithm that the hash did, but in reverse, you'd be able to decrypte a hashed message. However, modern hashing algorithms generate a lot of random variables in order to achieve the kind of encryption we want, (as do other encryption methods, not just hashing). Basically, there's really no way of knowing what and MD5 hash, for example, used for variables in the encryption process, so it's very, very difficult to reverse-engineer that hash.

You guys all bring up good points. I certainly had my "Security 101" from reading this. However, I was more caught on the ideology behind "everything encrypted can be cracked/decypted"

I believe the person who said that to me was concerned with the lack of certainty. he feels that computer security is all about prevention, and correction, it doesnt have any merits to it.

What do you guys think about that? I really didnt know what else I could tell him, I personally feel that "security" in general are all "prevention"-type actions, cops dont provide certainly a safe place, nor do computer security people. However, where do we find the certainty then?

For example, my job involves some general-public personal information that I am suppose to secure with reason measures like file protection and permissions. If say someone is successful in cracking them, and uses those against me, what kind of merit do I have to show that I did what I could? If security and encryption is not "for sure", where is the line of responsibility drawn? How do you seperate between what the person is responsible for, and what is outside of his/her scope?

Sorry if this is totally off topic...but I think it caught me off guard to hear and be thinking about this. Thanks for any comments!

Webmaster · September 2006

sprkymrk wrote:

(Crud, webmaster beat me to the punch! Durn those fast typing programmers! )

That's probably because I started typing half an hour earlier

What do you guys think about that? I really didnt know what else I could tell him, I personally feel that "security" in general are all "prevention"-type actions, cops dont provide certainly a safe place, nor do computer security people. However, where do we find the certainty then?

Security is about reducing the risks, not eliminating them. Even though the latter might be possible in certain situations, it's often a trade of between security and money (budget) and security and accessibility. I.e. you can encrypt an email message burn it on a CD, built a titanium box around it and bury it on the bottom of the ocean. That would be expensive though and obvously it won't be very easy for legitimate users to access the message.

If you haven't yet, I suggest reading my Risk Identification TechNotes. Not about encryption, but very closely related to your questions/discussion.

Danman32 · October 2006

Webmaster wrote:

Security is about reducing the risks, not eliminating them.

I had that very statement in my mind before I got to your post.

Bighorn, ask your friend if he locks his house and car doors. Locking them, having alarms and in the case of the car, an immobilizer won't eliminate the risk of theft, but would significantly reduce it.

Banks have their vault walls fortified, not just the door locks, because there is a whole lot more at risk than what you have at home. Otherwise everyone would have to put up thick hardened steel or titanium walls.

Same with networking. Military use heavy network security, but they pay for it in convenience and processing power. The home user is fairly well guarded by NAT and a good personal firewall. He won't need to 3des his entire HD and run IPSec to the ISP.

But bank vault walls can be cut into, cars can be towed, home windows broken, and computer encryption cracked... eventually.

Hashing has me think, I don't need to know the person's exact password, only a password that will match the hash. Most of the time though, the hash is only relevent for that transmission.

encryption

Comments