27

Today I had a hard time explaining the difference to a friend.

I know seeds are used when generating "random" strings. And salts are used when providing different outcomes to a hash.

What is a better way of describing these concepts and their possible differences.

  • 2
    your words here seem clear - what did your friend respond with? what was he confused about? – schroeder Feb 4 '15 at 23:43
  • 2
    Where did you come across the term "encryption seed"? That is not a standard term. Did you mean a seed for a pseudorandom number generator? Did you mean "encryption key"? Something else? Give us something more to work with -- otherwise to help you out, we have to guess what might be going through your mind and your friend's mind, and mind-reading is notoriously error-prone... – D.W. Feb 5 '15 at 23:41
44

Seed:

Encryption is powered by random numbers, but how do you generate a truly random number? The current millisecond? The number of processor threads in use? You need a starting point. This is called a seed: it kicks off a random number.

Salt:

When you hash a string, it will always end up with the same hash.

foo = acbd18db4cc2f85cedef654fccc4a4d8 every time.

This is a problem when you want to store things that you want to keep truly hidden (like passwords). If you see acbd18db4cc2f85cedef654fccc4a4d8 you always know that it is foo. So, you simply add a "salt" to the original string to make sure that it is unique.

foo + asdf = e967c9fead712d976ed6fb3d3544ee6a

foo + zxcv = a6fa8477827b2d1a4c4824e66703daa9

So 'salt' makes a 'hash' better by obscuring the original text.

| improve this answer | |
  • 1
    Very over-simplified explanation until I know more about the misunderstanding at play. – schroeder Feb 4 '15 at 23:54
  • 6
    The explanation for seed only makes sense if you first understand that computers only generate pseudorandom numbers, and what that means. – Ajedi32 Feb 5 '15 at 14:23
  • 2
    @Ajedi32 if the OP's explanation confused the audience, then I wasn't going to try to explain pseudo-randomness. – schroeder Feb 5 '15 at 17:46
10

The simplest terms I can think of:

  • A seed is a random value which generally has to be kept secret or the encryption is broken
  • A salt is a random value that is generally not a secret, which is used to make some precomputed attacks harder

I like to use those because the idea of keeping things secret or not is something meaningful to anyone.

| improve this answer | |
  • 1
    seed does not need to be secret: en.wikipedia.org/wiki/… – schroeder Feb 6 '15 at 1:28
  • 4
    @schroeder: I think you misread that on wikipedia: " A requirement for a CSPRNG is that an adversary not knowing the seed has only negligible advantage in distinguishing the generator's output sequence from a random sequence." I read that as "(an adversary not knowing the seed) has only a negligable advantage..." If you know the seed, you can perfectly predict the output of the PRNG in polynomial time, which is ReallyBad. – Cort Ammon Feb 6 '15 at 1:57
  • 1
    As a general rule of thumb, the primary focus of cryptographic PRNGs is to keep the attacker as far away from the internal values (like seeds) as humanly possible. As an example, the reason a Mersense Twister is not considered cryptographic is because you can recover the seed with 624 sequential outputs, and then you can perfectly predict the output of the Twister from then on out. – Cort Ammon Feb 6 '15 at 1:57
  • 2
    you are absolutely correct, I have had a misunderstanding all along. I just read the NIST guidance and they support your statements: csrc.nist.gov/publications/drafts/800-90/… Section 8.6.6 – schroeder Feb 6 '15 at 2:13
  • my misunderstanding stemmed from the requirement for reseeding, which I understood to mean that even if a seed was known, it would have little value to the encryption created from that value, which is not correct but that reseeding protects the CSPRNG as a whole. – schroeder Feb 6 '15 at 2:16
5

Your friend is actually justified in his confusion, because there isn't a big difference. At a high level, each is used as input to modify the output of a scrambling function.

Try emphasizing the difference between a hash function and a random number generator, and what they are typically used for. Also, be able to distinguish between a regular random number generator used for statistics (which can use a predictable or known seed), and a cryptographically secure random number generator used for secret key generation (which requires an unguessable source of entropy as a seed.)

| improve this answer | |
  • 2
    Yeah, it seems like overlapping terms spawn a lot of confusion when reasoning about abstract concepts. For example, I would still typically say that I'm "seeding" the secure RNG with a source of entropy. I need a linguist STAT! – AJAr Feb 5 '15 at 1:49
0

PRNG(seed)=a string of random numbers

hash(salt+password)=hashed password

The random number generator highlights the fundamental nature of computers. They are not random. Even the perceived randomness is not random, but close to random, though one might eventually pull out that old hat example of walking half distances towards a goal and never really reaching it.

| improve this answer | |
-1

The encryption seed is used to help generate a pseudo-random number. The seed is used to initiate the generation of a series of pseudo random numbers and increase the statistical randomness of the algorithm used. You can never really generate a truly random number via computation alone which allows some skewness on a probability curve showing the distribution of numbers generated by a pseudo-random number generator. The greater the probability of predicting correctly, a pseudo-randomly generated number the less secure the encryption is. The seed is usually taken from the time at the moment the encryption process is occurring, since that is an easy value to pull from the computer. If the seed is shared between systems it can be the private key in a private-key/public-key encryption model.

A SALT is usually a randomly generated string which a system will store rather than a user's password in plain text. A hash has to be stored alongside the SALT which is generated from the value of the user's password (entered at time of operation) concatenated to the SALT. This means that the system will never store the user's information directly and will rather compare the hash stored in the database or data store to one generated when the user enter's their password. This is more secure on several levels such as if the system's database is breached then the user's password will not be directly exposed to an attacker.

| improve this answer | |
  • I have some code examples from live enterprise systems which I am allowed to post as examples, if that would help clarify anything. – TRex22 Feb 5 '15 at 10:55
  • 1
    This answer seems a bit confused/confusing. There's no such thing as an "encryption salt". Salt is used with hashing, which is not the same as encryption. Similarly, there's no such thing as an "encryption seed". I've never heard any cryptographer call the seed for a PRNG an "encryption seed" -- it's a seed for the PRNG, or just a seed, but not an "encryption seed". Perhaps edit to adjust your terminology? – D.W. Feb 5 '15 at 23:42
  • The SALT is just called a SALT. I corrected my mistake. I have heard of the seed used in an encryption algorithm as an encryption seed. A seed may refer to many different things like the world seed in Minecraft. Just calling it a seed would be more confusing. – TRex22 Feb 6 '15 at 8:51
  • 2
    This answer still contains many confusions. You have incorrectly described what a salt is. A salt is not a hash. Salt is not an acronym and is not spelled "SALT". I don't know what you mean by "skewness"; that part of the sentence seems like gibberish. – D.W. Feb 6 '15 at 21:02
  • 1
    Sorry about that, the skewness I refer to is what is created when a normal distribution is skewed due to a variable in an algorithm affecting its result. – TRex22 Feb 7 '15 at 20:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.