Does AES encrypting /dev/zero and feeding output to AES again increase entropy of the ciphertext? I just thought about what would change if would pipe the output of

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2&gt;/dev/null | base64)" -nosalt &lt; /dev/zero | pv -pterb  &gt; file


to AES again. What this does is take a passphrase out of urandom and encrypt the output of /dev/zero - so taking 1 passphrase and an endless number of zeros, which outputs random numbers. this way AES is used as a random number generator. This line can be used to fill up a file on a disk with random numbers. It's way faster than dd'ing /dev/urandom to a file. One can also substitute "file" with /dev/null, just to see how fast the system is encrypting and writing to null.

So I wonder what happens if I would feed the output of that line to AES again. **Would the output change in a way?

As I think it should not change anything — the randomness of the output should be exactly the same, shouldn't it? Is there a practical way to measure the entropy of the output?** I think no, as it should be good enough to not have any statistical anomalies, so there's no way of measuring an increased/decreased entropy - or am I missing/confusing something?
First lets quickly analyze your commands:


$(dd if=/dev/urandom bs=128 count=1 2&gt;/dev/null | base64) : take a block of 128 pseudo-random bytes and put it into a single line encoded as base 64, throwing away anything printed to standard error
openssl enc -aes-256-ctr -pass pass:(1) -nosalt &lt; /dev/zero :


perform OpenSSL key derivation on the base 64 string from step (1) without a salt: basically two subsequent runs of HMAC-MD5 to create 256 bits of output;
use the resulting key to perform AES-256 CTR encryption on an endless stream of zeros to get to the counter mode key stream;

pv -pterb &gt; file : perform some metrics before dumping the key stream to file.




Now your question is if you would replace the /dev/null with the input file, using a new block of 128 bytes taken from /dev/urandom as password. Well, the good news is that it will add another amount of randomness to the original stream. How much entropy that entails depends on the internal characteristics of the used /dev/urandom implementation. Of course, if you would use the original password then you would cancel out the operation and produce a file with all zeros.



Using CTR to create a fast PRNG is a good idea that is used quite a lot. But remember that although it is very fast, it doesn't reseed. Using /dev/urandom is a bad idea if you want to have as much entropy as possible though. For this kind of use /dev/random is a better choice.

Using a bad password generation mechanism such as the default OpenSSL one will however bring back the maximum amount of entropy to 128 bit max due to MD5 being used to derive the key. If you consider that you could have up to 128 bytes of entropy, that's quite a shame. You would be better off using the -K option which allows for hexadecimal encoded keys instead. In that case you retrieve 32 bytes of randomness and use the full 256 bits of that directly for AES-CTR.

So if you want to increase the possible entropy, try and use this:

openssl enc -aes-256-ctr -K "$(dd if=/dev/random bs=32 count=1 2&gt;/dev/null | od  -v -An -tx1 | tr -d ' \n')" -iv 00000000000000000000000000000000


and use it on any number of zeros. Note that on some systems this may deplete the entropy pool if you perform a lot of these commands.

Here -K is used to replace the password with a 256 bit key, which is supplied in hexadecimals using the dd if=/dev/random bs=32 count=1 2&gt;/dev/null | od  -v -An -tx1 | tr -d ' \n') command, where od creates hexadecimals including spaces and newlines, which are removed using the tr command. The IV can be kept to all zero as the key will differ for each command anyway.



Final note: writing random data to an intermediate file is usually not a good idea. You are much better off programming this. In case you require OpenSSL then you could use C or any wrapper library for your choice of language that gives you enough functionality.