# What’s the difference between a secret key and a seed?

I always hear that if you have the seed then you can easily obtain the key. So, is the secret key just typically an expanded version of the seed? If so, via some key derivation algorithm?

Also, if you can easily obtain the key when you have the seed, why don't we just use the seed as the secret key instead?

• Maybe you could clarify what kind of keys you are talking about and in which context. – Maeher Feb 1 '18 at 5:07
• As you can see the answers kind of revolve about what is meant with the word "seed". Any protocol references would be appreciated (which is kind of the same thing Maeher is asking for, in different words) – Maarten Bodewes Feb 1 '18 at 13:31

I suspect that what you're referring to is the operation of a pseudo-random number generator (PRNG). It takes a seed as input, and produces a random-seeming series of outputs.

If you derive a cryptographic key from the outputs of the PRNG, then the key chosen depends on the seed. If an attacker knows the seed, they may well be able to (much) more efficiently guess the key.

If the seed is created using a source of randomness (as compared with a source of pseudo-randomness), then, at least in part, it is not predictable, and the resulting outputs of the PRNG are not predictable. If you then throw away the seed (so that it can't be stolen after the fact), you should be able to use the key with some confidence.

So, is the secret key just typically an expanded version of the seed? If so, via some key derivation algorithm?

I would say that while it is worded a bit oddly, you could probably look at the secret key as an "expanded version of the seed." The process is slightly more complicated than just via the key derivation algorithm, because you omitted the PRNG. So: seed -> PRNG -> key derivation algorithm -> key

Also, if you can easily obtain the key when you have the seed, why don't we just use the seed as the secret key instead?

The short answer is that the seed has a small amount of real randomness that takes time and effort to acquire. By contrast, the PRNG changes that seed into significantly more pseudo-random output very quickly / cheaply.

You can definitely use the seed (or, a series of seeds, presumably, since you probably need more data than just one seed contains) as a data source to generate your key. (seed1 + seed2 + seed3 + ... + seedN) -> key derivation function -> key, omitting the PRNG.

The reason it isn't done that way is because:

• True random (as distinct from pseudo-random / PRNGs) sources are much much slower and more expensive
• Key derivation functions are potentially very sensitive to any predictable information in the input data. That means that input data (e.g. your seed) that is even partially predictable is dangerous. So you would need the seed to be generated completely from a slow, expensive, true random source rather than just having a fraction of the seed be truly random.
• You need a significant amount of data, so you need more than just one seed. See above about each one being expensive by comparison to PRNG output.

Secret keys of $n$ bits should consist of $n$ bits that are indistinguishable from random to an adversary. Although seeds may contain the right amount of randomness that doesn't mean that randomness is contained in $n$ bits; often the randomness is spread out over multiple bits, where some bits only contain some randomness or even no randomness at all. In that case you cannot just take $n$ bits from the seed or perform a simple arithmetic operation over the seed (such as XOR-ing the bits together).

So a Key Derivation Function can be used to extract the randomness from the seed. If the input already contains enough entropy then the KDF is usually a Key Based KDF or KBKDF. Besides that, it is also possible to expand the amount of keying material from the KDF. The amount of randomness will however not increase, so this is mainly useful to extract more keying material (a MAC and ENC key or ENC key and IV, for example) from the same seed. Alternatively the KDF can be run multiple times over the same seed, where the key also depends on additional data (a label or more generically, info). A salt may also be used as input, which makes it easier to prove the security of the KDF. HKDF is a modern KBKDF that clearly distinguishes between randomness extraction and expansion.

Such a key derivation function is a Pseudo Random Function as the output is random if you don't know the seed. In TLS 1.2 the name key derivation function or KDF is missing: instead it is replaced by the more generic PRF name.

Beware that often pseudo random number generators (PRNG) are also thought to be KDF's. But although they are very similar, I would not use any random number generator to create output keying material. Especially when it comes to implementing a random number generator different requirements must be met. For instance, it could be that the random generator changes algorithm or that it uses additional seed. In that case the output of the random number generator changes, and it would therefore lead to different keys. In the worst case you cannot regenerate the output key material at all, which means that any message encrypted with those keys is lost as well.

The seed is also often called input keying material.

A key is kept unmodified for use without transformation during all its useful life, and is typically shared between several parties (perhaps partially: in asymmetric cryptography, only the public part of a key is shared).

A seed is usually used once to initialize some variable which will changes over time, and often is not shared at all. The term seed is often used for what defines the initial state of a Pseudo-Random Number Generator.

The statement "if you have the seed then you can easily obtain the key" seems to refer to a PRNG used to draw a key; in that context seed is the input of the PRNG, and key is the PRNG's output (the key of another cryptographic function).

• I agree that this is technically correct. However, from the question I gathered that the seed in this case should be considered to be the (shared) secret or, if it is used with a KDF, the input keying material of that KDF. – Maarten Bodewes Feb 1 '18 at 13:28