I have some sensitive information in a MongoDB collection which needs to be encrypted and decrypted. Only one section needs to be encrypted, so I could use the other values as a form of entropy. I have two ideas:
Generate a pseudorandom key from the other keys in the document, and have each document use a different key
Use one key for all the databases
I feel like the former would be more secure, but what would be a good way of making the pseudorandom generator?
If the first is a poor idea, what would be the best way to store the key for the databases?
I have an authentication application and don't know how secure it is.
here is the algorithm.
1) A clientToken is generated by using SHA512 hash a new guid. I have about 1000 ClientsToken generated and store in the database.
every time the caller calling my web service it need to provide the clientToken, if the clienttoken does not exists in the database, then it is not valid client.
The problem is how long does it take to brute force to get the existing ClientToken?
A GUID is a 128 bit value, with 6 bits held constant, so a total of 122 bits available. Since this is your input to the hash, you're not going to have 2^512 unique hashes in your application. This is roughly 5.3*10^36 values to check.
Say your attacker is able to calculate 1,000,000 (10^6) hashes per second (I'm not sure how reasonable that is for SHA-512, but at this size, a few orders of magnitude won't influence things that much). This works out to about 5.3*10^30 seconds to check the space (For reference, this will be far beyond the time all stars have gone dark). Also, unless you have several billion clients, a birthday attack probably will not remove too many orders of magnitude from this.
But, just for fun, let's say the attacker has some trick that lets him reduce the number of hashes to check by half (or some combination of reduced space to check and increased speed), either by you having that many users, or some flaw in your GUID generator, or what have you. We're still looking at well over 100 million years to find a collision.
I think you're beyond safe and into somewhat overkill territory. Also note that hashing the GUID in effect does nothing, and that GUIDs probably are not generated via a secure random number generator. You'd actually be a bit better off just generating a 128 bits (16 bytes) of randomness via whatever secure random number generator your platform uses, and using that as the shared secret.
What is the purpose of saltkey in the t-sql. For example in aspdotnetstorefront databse there is a table name customer, we encrypt/decrypt password then there is another field called SaltKey, what is the purpose of it?
Your question is vague, but I think you are looking for information about a salt, which is a cryptographic concept and not a relational database one. From Wikipedia:
The benefit provided by using a salted password is making a lookup
table assisted dictionary attack against the stored values
impractical, provided the salt is large enough. That is, an attacker
would not be able to create a precomputed lookup table (i.e. a rainbow
table) of hashed values (password + salt), because it would take too
much space. A simple dictionary attack is still very possible,
although much slower since it cannot be precomputed.
See here http://en.wikipedia.org/wiki/Salt_%28cryptography%29 it has to do with encryption and not T-SQL
better look http://en.wikipedia.org/wiki/Salt_%28cryptography%29
see here http://crackstation.net/hashing-security.html
this will help you out to find what is salt..
Can I create a really short SHA1 hash to uniquely identify an object that would typically have an id like 1300992607?
This is relatively a theoretical question but how short can a SHA1 hash be and still be unique for an objects id? Please help me if not asking the right question here.
No, you can't, a hash doesn't work that way.
You can create a hash for the id, and just take as many bits you like from it. The more bits you use, the less likely it is that you get a hash that is the same for two different id, but no matter how many bits you use from the hash there is still no guarantee that there will never be a collision.
For my iPhone application, Apple wants to know if my password encryption (md5) is greater then 64-bit symmetric or greater then 1024-bit symmetric. I have not been able to find it online, so I am wondering if anyone knows the answer. In addition, is this considered an appropriate encryption technology for passwords, or should I use something different?
Thanks for any help!
MD5 is a hashing function, thus by definition it is not reversible. This is not the case for encryption (either symmetric or asymmetric), which has to be reversible to be useful.
To be more precise, hashes are one-way functions, in that an infinite number of inputs can map to a single output, thus it is impossible to obtain the exact input, with certainty, that resulted in a given output.
However, it may be possible to find a different input that hashes to the same output. This is called a collision.
Generally, hashing passwords instead of storing the plain text (even encrypted) is a good idea. (Even better if using a salt) However, MD5 has known weaknesses (and large collections of rainbow tables that aid in finding collisions), thus it would be a good idea to switch to something like SHA-1 or one of the SHA-2 family of hashes.
However, to answer your original question, there is really is no way to compare MD5 or any hash against any type of encryption; they have no equivalents because it's like comparing apples and oranges.
md5 isn't really symmetric or asymmetric encryption because it isn't reversible either symmetrically or asymmetrically. It's a Message Digest (secure hash) algorithm.
It's not encryption, it's a digest. If you didn't salt it, it's not particularly secure, but they're asking you the wrong question.
What exactly are you doing with MD5 and passwords? There are standard ways of doing things here, and it's always better to use one, but without knowing what you want to do it's hard to point you at a relevant standard.
It is NOT encryption at all.
Apple asks the question about the use of MD5 for hashing passwords to see if it requires authorization for export from the Department of Commerce/Bureau of Industry and Security.
The answer for that purpose is that using MD5 for password protection is not controlled as strong encryption (like symmetric algorithms in excess of 64 bits) in accord with the Technical Note to 15 CFR part 774, Supplement 1, ECCN 5A002, paragraph a.1, which describes using encryption for password protection. However, it may still be controlled under ECCN 5A992.
http://www.bis.doc.gov/encryption/ccl5pt2.pdf
The other answers are not helpful in the context of why the question was asked.
Also, you may want to call the Department of Commerce/Bureau of Industry and Security at 202-482-0707 and ask about your specific application.
Hash function most of times is a way to compress your data. They are one-way hash functions, meaning that are difficult to reversed(having the hash function=digest of a message it is difficult to find the original message that is converted to the specific hash value). On the other hand, are very easy to implemented because there is no need of any type of key.
It is not a symmetric or asymmetric algorithm. These kind of algorithms are used to encrypt and not to hash data. Encryption is used for confidentiality reasons, to protect data from attackers where they try to read someone's.
Encryption or cipher algorithms need keys to perform their tasks in contrast to hashes where they do not need any kind of key. Hashes are not used for confidentiality reasons but for integrity reasons even if they do not have enough strength. MD5 is one type of a hash function where exists many others because MD5 is not strong enough
I think MD5 is used for better security.... if we tell about any encryption or decryption algorithm, they are just for converting any plain text into cipher text... but on the other hand MD5 provides an uniqueness on that plain text that would be sent by any source(Alice)...so we can say that for better security or for providing envelop on plain text MD5 should be used before using any encryption algothim(symmetric or asymmetric).
As the numerous other guys on here have mentioned, MD5 is not a symmetric or an asymmetric algorithm.
Instead it comes under a different branch in cryptography all together. It's one of the smallest hashing algorithms available in the .Net framework. At a mere 16bytes for its keysizes, which should be 128 bit. Something that you learn your bread and butter with.
So yes it is greater than 64bit which is only 8bytes in size.
The maximum key size the common symm' enc' algs use is 256bit (Rijndael Managed).
If you want to be looking at keysizes greater than that, then you can use the RC2 symm' enc' algs which supports variable key sizes. Something that you can experiment with?
If you want higher than 1024bit, then you need to be looking at Asymm' Enc' Algs like the RSACryptoServiceProvider class which supports key sizes going upto 16K in Bits I think?
If you want to use passwords, then you need to use Keyed Hashing Algs, like anything HMAC' something, they should be Keyed Hashing Algorithms or MacTripleDes. These all use secret keyes to encrypt the hash that is generated from the data you supply. The keys are created by using passwords and salt values via the RFC2898DerivesBytes class. <-- Don't forget that RC2, Rijndael, AES, DES and etc all can be set-up to use passwords to help derive the secret keys. In case you are thinking that the opening sentence of this paragraph is a little misleading. So i added this just to be sure in the event that hashing is not what you need altogether.
*REMEMBER THAT THERE ARE UNIQUE INHERITANCE HIERARCHIES IN .net's Cryptography NameSpace.
So MD5 is the base Abstract class all MD5 Derived classes are to derive from. .Net provides one such derived class that is called MD5CryptoServiceProvider class. Which is essentially a managed wrapper class that makes call to windows unmanaged Crypto-Libraries API. MD5 is known in MS official textbooks under the umbrella term as a Non-Keyed Hashing Algorithm. *
There are plenty of options available to you.
: ) Enjoy !