Best way to use a block Cipher as RNG

I am using some block Ciphers (AES and Threefish in particular) as RNG for the purpose of parallel Monte Carlo simulations. For each key, simply encrypt a sequence of counters produce a random stream more than good enough for the specific purpose. I don't. need CSPRNG. The use of these ciphers are because good performance (<1 cpb in my implementstion) and easy to setup multiple streams in parallel environment.

For each thread, a new cipher with a new key is used. Each thread has a different key. For the purpose of my simulation, it is sufficent that the two streams of any two threads are statistically independent. Now my questions is that what is better way to seed each thread.

The first i am considering is simply seeding each with a counter as key, so, thread 1 has key equal to 1, thread 2 has key 2. And so on

The second is to use a seemly random key. For example, Say the cipher in use is AES256, for thread 1, I encrypt value 1 (256bit integer) with a zero keyed Threefish256, and a "random" 256bit number as key for the AES256 cipher. And so on for each thread. Since Threefish as a cipher is also a bijection, there's no risk that two threads having the same keys, up to 2^256 threads, which is far more than enough.

Which of the two will be better?

Edit I meant to post it as a comment to the answer, but it was too long.

The indistinguishability is the part I don't quite understand. In fact I have read that wiki article for a couple of times before posting this question. Please bare with me. If I understand correctly, the basic principle is that knowing the cipher text without the key, one cannot guess the plain text with any advantage. In other words, given two almost identical streams, or highly correlated streams, and knowing the key of one stream, does not give any advantage of guessing the key of the other. However, my problem is more or less the inverse of this. Does two different keys, either random or related, always produce two uncorrected stream? My intuition is yes, since there are 2^k keys while there are (2^n)! permutations of the period 2^n streams, where k is the bits of key and n is bits of block. Or another way is, is it always the case, that for two keys, k1 ≠ k2, the cipher streams will be apparently uncorrelated? I understand that for k1 = 1, k2 = 2, etc., it should be so, at least if the total number of keys are not too big. But I am not sure if it is so for any two k1 and k2 from the 2^n possible keys.

• Is there any risk of the counter ever repeating such that it would hurt you? (eg if you restart your software and it restarts to count at 1, would that hurt your experiments if you'd get the same random numbers again?) Commented Oct 2, 2016 at 13:40
• Ever cipher ever used within one program always use a monodically increasing counter. So the counter won't repeat for the same key. Ever cipher will be started with a unique key with in a program (I use a singleton to produce keys). So as long as I save the state of that singleton between programs, I can make sure no two ciphers with same key are ever used within a project. Commented Oct 2, 2016 at 14:04
• [My feeling of the gut:] AES in counter mode is apparently very well pseudo-random, but I am yet not aware of any truly in-depth statistical analysis of it. Using two different keys, whether differing by a constant or by a random amount, would presumably have no consequences more significant than that of what an above mentioned, yet non-existing, in-depth statistical analysis would reveal. If you really need to have such concerns, I wonder whether you don't also have serious concerns of the quality of your simulation software (rounding errors, etc.) or perhaps also of the theory underlying it. Commented Oct 3, 2016 at 11:08

1 Answer

If we assume that your ciphers have the IND-CPA property (indistinguishability under chosen-plaintext attack) then both methods will be equally good.

However exact reproducability of the values can only be achieved by the first method.

• Thanks for the answer. However, as there's nothing nondeterminstic in the second method, why can't it be reproducible? As long as know the key of the Cipher that encrypt the key and the counter that being encrypt, I can always reproduce all the same streams. Did I miss anything here? Commented Oct 2, 2016 at 13:56
• I wrongly assumed that you won't store the random keys. Commented Oct 2, 2016 at 13:59