# Seed/key algorithm security

Currently I'm working on implementing a seed/key algorithm to limit access to a tool for authorized users. My understanding of the algorithm is that its strength is derived from the seed itself. However the majority of articles say "The basic idea is that the server provides a seed -- a short string of byte values -- and the client is required to transform that seed into a key using a secret algorithm." If the algorithm's security is based on the seed, why is it "a short string of byte values" instead of the longest possible string of byte values?

• A seed initializes a PRNG; it is not the key, so seed length doesn't inherently impact the security of the key material provided you have a strong PRNG and key algorithm. Commented Apr 13, 2020 at 19:12
• I see my misunderstanding now. So then a public seed wouldn't necessarily undermine the security of the algorithm either? Commented Apr 13, 2020 at 19:23
• What do you mean by "public seed?" A seed value, by definition, will generally result in a deterministic result. As a rule of thumb, and lacking any knowledge of how you're transforming the seed, you shouldn't make your seed value public if you want your generated hash or key to be unique. Commented Apr 13, 2020 at 19:27
• As it stands it is unclear what kind of algorithm or protocol you're trying to implement. And using a "secret algorithm" goes against Kerckhoff's principles. So please add information about what scheme you are trying for. Names, articles, anything. Commented Apr 13, 2020 at 22:22
• @MaartenBodewes To be honest, I'm only beginning my research so I don't have any examples yet. Thank you for referring me to Kerckhoff's principles I was unaware of them. Could you clarify for me how an algorithm and seed could be public yet the key remains a secret (not reproducible)? Commented Apr 15, 2020 at 18:02

"Short" and "long" are relative terms. If I secretly make 128 coin flips and write down the results, that sounds like a lot of coin flips, doesn't it? There's $$2^{128} > 10^{38}$$ combinations I could get, a number bigger than 1 with 38 zeroes after it, so you have no hope of guessing what results I got.
Yet that unguessable result fits in $$128 ÷ 8 = 16$$ bytes, which almost everybody would call short byte string. That is, it's short if you're trying to store it in a computer, but impossibly long if it was picked at random and you're a bad guy trying to guess it.