Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Can anyone suggest a good (CS)PRNG algorithm that takes advantage of having a very large (ideally arbitrarily large) seed? I'd like to use several kilobytes, perhaps several hundred kilobytes, of random data to generate up to a few dozen megabytes of PRNG output. The PRNG algorithms I'm aware of only take relatively small seeds: I'd like to make the most of the random input data I have.

share|improve this question
something I just came up with now: $\:$ partition the seed into seeds for standard PRNGs, and alternate $\hspace{0.4 in}$ their outputs. $\;\;$ (This would only work if your data pretty much is random, it could fail quite badly $\hspace{0.8 in}$ if your data merely had min-entropy close to its size.) $\;\;\;\;$ – Ricky Demer Jul 17 '12 at 12:31
Using more than a couple of hundred bits of entropy doesn't really increase your security. If you have a big seed, just send it through SHA-512 first, and use that as actual seed. – CodesInChaos Jul 17 '12 at 12:34
Thanks Ricky. No offense, I'm trying to avoid things that people "just came up with" =). I'm hoping there's a standard peer reviewed and time tested technique for doing this. Your idea sounds perfectly reasonable to me, but I'm no expert. Anyway, I think a variant of your idea would be to use Fortuna, or something very Fortuna like (i.e., set the number of entropy pools high enough to cover all of the input data). – sh1ftst0rm Jul 17 '12 at 12:35
@bmearns: You're trying to solve a problem that no halfway-decent PRNG has. So long as the PRNG isn't horribly broken, and so long as an attacker can't guess the seed, the output will look random and pattern-free over many, many terabytes. – David Schwartz Jul 22 '12 at 16:05
@DavidSchwartz: Ok, I think I finally get it now =). Just use a good PRNG and I don't have to worry about "making the most" of my random seed. That being said, it probably doesn't do any good to use a seed that's bigger than the PRNGs internal state, right? – sh1ftst0rm Jul 27 '12 at 13:16
up vote 3 down vote accepted

What you are doing sounds a lot like what the /dev/random and /dev/urandom or the PRNGD on many systems already do: those systems take an arbitrary large sequence of numbers (from a true hardware random number generator if available, or else from environmental noise such as keystroke timing) and feed it into a CSPRNG; the output is made available via /dev/random and /dev/urandom .

Perhaps you could somehow extract the source code implementation of any one of those systems, and make a user-level variant that, rather than getting input from environmental sources, only gets input from your large seed.

  • FreeBSD and AIX implement /dev/random using the Yarrow algorithm
  • OpenBSD implements /dev/random using an algorithm based on RC4 (is this the same as ISAAC ?)
  • Fortuna
  • My understanding is that many other CSPRNG implementations have a way to feed in more bits of entropy.
share|improve this answer
take a look at the paper I link to in my answer. Section 5.2 talks about some issues they see with Fortuna. While all academic, it is an interesting discussion. – mikeazo Jul 25 '12 at 11:54

The PRNG proposed by Barak and Halevi should be able to meet your needs and provide sufficient security.

Their PRNG has an API of next and refresh. refresh takes an arbitrarily long string and uses it to update the internal state of the PRNG. next returns some number of random bytes (if more is needed, one can simply call next in succession).

They prove some very nice properties of their PRNG (which together define robustness of a PRNG), and give a concrete implementation.

The entire paper is definitely worth a read.

share|improve this answer

Don't bother. Take any cryptographically secure CSPRNG. Feed it a random key (make sure the key length is at least 128 bits). You're done. Once the key length is 128 bits or so, any additional length is pointless overkill.

If you have a thousand-bit seed, just hash it first to get it down to be the right size of the key of your CSPRNG -- but make sure you have at least that much entropy in the seed. Or, better yet, simply generate your key using a secure pseudorandom number generator, like /dev/urandom or CryptGenRandom.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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