I want to run statistical tests on my implementation of AES. How should I convert it into a PRNG? Is there a standard way to go about doing this? I could not find much information about this although this was done by NIST while during the selection of AES back in the days.

  • $\begingroup$ AES-CTR-DRBG? $\endgroup$ – SEJPM Feb 5 '16 at 20:37
  • $\begingroup$ Will take time in order to go through. $\endgroup$ – levi1696 Feb 5 '16 at 20:46
  • $\begingroup$ TL;DR: Run AES in CTR mode and use your entropy rich data as IV and key. (OFB also works for this) $\endgroup$ – SEJPM Feb 5 '16 at 20:52
  • 1
    $\begingroup$ On the other hand, what is the point of running statistical tests on your implementation? If it is a correct implementation of AES, the statistical tests on your implementation will give the same results as any other implementation. If your AES implementation is not correct, statistical tests will not detect it (unless your implementation is horribly wrong); test vectors are the correct way to test for that. Yes, I know I'm four years late, however no one else seemed to ask "why would you want to in the first place?" $\endgroup$ – poncho Mar 13 '20 at 15:59
  • $\begingroup$ Besides test vectors, it is important that you test any possible edge cases or your implementation, although those may also be hit by the Monte-Carlo test. I've seen too many products that had their tests just rely on official specifications and test vectors while ignoring the design and implementation of the product itself. Actually, one of my products failed on that level as well (although, in my defense, I did explicitly ask also to take the design into account). $\endgroup$ – Maarten Bodewes Mar 14 '20 at 23:44

The answer is simple. AES is in itself a pseudorandom function, so an output from a single block encryption will produce 128-bits of pseudorandom numbers.

Now to use AES to generate longer sequences, you will have to use a block-cipher mode that lets you do the same.

Here is a small list of a few very popular modes ment for PRNGs:

  1. Counter(CTR): Counter mode turns a block cipher into a synchronous stream cipher. It requires an IV or nonce which is combined with a counter and encrypted with a block cipher. The counter can be any non repeating function, however a simple increment by one is secure enough, and not to mention, the most efficient.

CTR encrypt CTR decrypt

  1. Output Feedback (OFB): This also turns a block cipher into a synchronous stream cipher. It starts encryption with an IV, and operates by encrypting the previous block.

OFB encrypt OFB decrypt

  1. Cipher Feedback (CFB): This one converts a block cipher into a self-synchronous stream cipher. It starts with an IV, XORs the output to get the first ciphertext block, and uses every previous ciphertext block as the next IV. CFB encrypt CFB decrypt

You could also use other modes too, but they might not be well suited for use in stream ciphers, so they will be slow. Otherwise, the ultimate answer to your question is to use a secure block cipher mode. And, not to mention, they work well with hash functions as well.

  • $\begingroup$ my guess is that these constructions are too naive and no one uses them. For example they both do not provide forward (from the state you can obtain all previous random numbers) and backward (from the state you can obtain all future random numbers) security. NIST SP 800-90A defines a CTR-DRBG that probably adds these properties to AES-CTR nvlpubs.nist.gov/nistpubs/SpecialPublications/… $\endgroup$ – David 天宇 Wong Aug 25 '19 at 22:57

As David Wong commented, NIST has proposed CTR-DRBG as the secure way to do it. Here is a link to an implementation in Python using CTR-AES-128.

However, it should be noted that quite recently (2019-11) a side-channel attack was published (by Lauren De Meyer, COSICS) to recover the key and a nonce using only 256 power traces of CTR-AES.

Thus, one should be very careful when generating many random numbers from CTR-AES if adversaries have knowledge of power consumption of the device.

  • 3
    $\begingroup$ Note that this is a DPA attack (that is, it assumes that the attacker can make very precise measurement of the current on a per-nanosecond basis) against an AES implementation that is not hardened against that attack. I believe that saying "there's this attack model where there exists an AES implementation that is weak, hence we must limit our use of AES in all cases" is not fully justified (although, if you are in a situation where side side channel attacks are plausible, care would certainly be warranted…) $\endgroup$ – poncho Mar 13 '20 at 14:34
  • $\begingroup$ Good point! I corrected the answer that the attack assumes access to the power consumption. $\endgroup$ – user41844 Mar 14 '20 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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