Difference between encryption and hashing

Question

In our project there are several places where we could've gotten away with hashing. For example, we store an encrypted reference between a license and the licensed object in the database along with the unencrypted reference. This is to ensure that the user can't change the entity they have licensed by mucking with the database.

The main reason we use encryption everywhere is that we already had a nice encryption library and a system key. It didn't really seem worth the time to develop a hashing library in addition.

Is there any security risk we're creating by using encryption instead of hashing?

Answer 1

By storing the plain text along with the ciphertext you are creating a nice repository of test strings if someone would want to find out your key. Since you apparently use said key for encrypting everything I'd say it is a risk.

Remember, the nice thing about central databases is that some day someone will get the data. If history is any lesson, at least.

Answer 2

If it is a symmetric cipher you are using, and the system is deployed in the 'hostile' environment, then it is a question of time before a motivated individual can isolate the key and sign their own (or others) license data.

In those cases you need an assymetric cipher to "sign" the license with your private key which is stored safely away on a computer in a vault and no connection to the outside world. Ok, slight exageration, but in a secure environment.

A plain hash will not help in this case because they can be used to sign forged licenses. If you want to be sure that only you can approve license changes, then using an assymetric cipher to encrypt the license (or a hash of the license) is the most straightforward way.

Answer 3

Well, encryption is a two-way process. Assuming you are using a key-based encryption, you are safe as long as the encryption key is safe and you're using a modern algorithm (say, AES). Hashing, on the contrary is a one way process, that it should be practically impossible to reconstruct the hash input from the hashed value. So, not having a key, hashing may be considered safer. It may also be less computationally hungry.

Answer 4

Any data that can be encrypted can also be decrypted.

Hashing is a one way process, especically if you use the new SHA2 methods.

Answer 5

From what I understand you want to achieve integrity of your data (i.e. you want to achieve that nobody can change you're data unnoticed). This can be achieved by used a Digital Signature (e.g. RSA, DSA) or a MAC (Message Authentication Code). A mac is the symmetric equivalent of a digital signature, which is usually an asymmetric scheme.

So in your case, a MAC (like for example HMAC) should be a good choice!

Answer 6

You've introduced the secrecy of the key as a weak point, I would say it's a risk, though gauging the severity would take more details.

Hashing, on the other hand, would rely solely on the difficulty of finding collisions, which is probably a more secure scenario than keeping that key secret.