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$
$\endgroup$
5
-
$\begingroup$ AES-CTR-DRBG? $\endgroup$– SEJPMFeb 5, 2016 at 20:37
-
$\begingroup$ Will take time in order to go through. $\endgroup$– levi1696Feb 5, 2016 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$– SEJPMFeb 5, 2016 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$– ponchoMar 13, 2020 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, 2020 at 23:44
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
1
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:
- 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.
- 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.
- 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.
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$ Aug 25, 2019 at 22:57
$\begingroup$
$\endgroup$
2
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$– ponchoMar 13, 2020 at 14:34
-
$\begingroup$ Good point! I corrected the answer that the attack assumes access to the power consumption. $\endgroup$ Mar 14, 2020 at 20:59