4

This question is related to this one in intention, and this one in scope.

Would I be guarding myself against future attacks on a single PRNG if I combine two (or more) together?

I am thinking of using the Fortuna PRNG together with AES in counter mode, each initialised by a different source of entropy (now exactly what the two sources will be is an open problem). The output of each will be combined with the XOR operation, they will run on a separate thread and computational power is not a problem.

My (informal) thinking is that, as long as one function remains unpredictable (in polytime), the output is secure (in polytime).

The answers may address Fortuna or AES specifically, or they may treat the generators as abstract functions. Is there a flaw in this design?

Community
  • 1
rath
  • 2,598
  • 3
  • 27
  • 40

2 Answers2

3

It should not be possible to attack this scheme itself. The XOR function will work like a one time pad, where the output of each PRNG can be either the plaintext stream or the key stream. So the output of the function should be random as long as one of the two streams can be thought to be a secure and well seeded PRNG.

In real life scenarios the main cause for concern is not the PRNG itself; the source of entropy (seeding) is much more of a concern. In this scheme entropy is exchanged for a more secure PRNG. It is questionable if this is worth the cause. Using the same entropy is for both PRNGs is not a good idea, it may open the scheme to attacks and will certainly invalidate any security proof.

Furthermore, synchronizing the streams generated by the threads may require large buffers which are effectively representing the state of your new PRNG. It is required to deal with thread synchronizing issues and overhead as well and it is important not to leak any state while doing any of this. It may be easier to put the two functions in the same thread to maintain a small state.

In conclusion, I don't think there are theoretical issues with your scheme, but I don't see how it would be a practical scheme. Most importantly it seems to solve an issue that is not really present. You trade entropy and speed for a more secure PRNG, which is not likely to be a cause of concern in the first place.

Note that I don't see how the results of Boneh and all apply to the new PRNG. Their results are used when multiple hash functions are used on the same data, possibly using XOR. I don't see how it would apply on generating a key stream. That said, it is questionable if any attacks on the underlying hash function translate to the PRNG anyway.

You are likely better off using the additional entropy to reseed more often.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
0

I understand your question to be related with stream encoding by XORing a source using the bytes emitted from two by XORed PRNG. (By the way, you don't need to combine them before XOR the source - the result remains the same, if you XOR the source by bytes from both PRNGs in the same sequence.) I guess, you want to be able to decipher the result back to the source.

Thus you will use a symmetric key to seed for encoding / decoding. And in practice you will use the same key (or keys deriving from the same source, i.e hash(key)/reverse(hash key) or hash(key)/ (other-)hash(hash(key))..) for both PRNGs.

Using two PRNGs will have the effect, that an attacker even knowing one PRNG+key will not be able to decode the cypher. But your primary concern will be the key secret anyway if the keys derive from the same source(see above).

Good PRNGs are designed to produce equally distributed byte streams (baskets 0:255). The distribution pattern might be broken by your approach. Breaking the distribution might or might not be a problem (i.e. think text-encoding vs. steganography).

Using two PRNGs (or one with two different seeds) with a lower risk of changing distribution patterns can be accomplished by toggling the byteStream between two PRNGs like x[0] ^prng-1 , x[1] ^prng-2, x[2] ^prng-1 …

The latter design would furthermore prevent performance losses. On the other hand, a scheme should not been used on clear text / images … better use it with compressed/encapsulated or otherwise obscured sources to prevent guessing from a half decoded cipher fragment (one prng-seed combination known by the attacker).

ABri
  • 209
  • 2
  • 9