Fortuna MFC GUI Monitor

I have developed an MFC application (Dev Studio .Net Project here) which generates passwords and has a monitor to allow for viewing of the internal state of the Fortuna prng. 

The Password Generator

Here is the password generation dialog:

Note that repeated characters are allowed in the password (this makes it more difficult for someone doing a brute force search of all possible passwords).  I also use the method of choosing password characters outlined in the book "Secure Programming Cookbook for C and C++" by John Viega and Matt Messier.  See recipe 11.11 "Getting a Random Integer in a Range" for all the gory details.

The checkboxes are provided to limit the symbols used in the password.  If you don't want the punctuation characters ! etc, disable that checkbox.

If you only want to run (as opposed to debug and see the source code) the password generator program, here are the required binaries.  Note that this also includes the monitor described next.

The Monitor

In the code I've used the preprocessor symbol FORTUNAMONITOR to turn monitoring on and off.  In a production environment the extra data members and data cache used to measure the compressibility of the raw data should not be used.

Each pool object has a hash of the current pool state as well as a vector to accumulate incoming data (called the raw data).  When the incoming raw data exceeds 1024 bytes, they are appended to the current hashed state and a new hash is determined.  Then the raw data vector is erased and the 'Compact Pool Count' counter is incremented.

The source info allows the raw data for each source to be viewed in the 'Peek' edit box.  In this example the data for Ping is being examined.  Each source can optionally turn on the Compression test to test for total failure of the data source.  Just because a source has low compression does not mean that it is a good source of cryptographically strong random data, but it does give an indication if the data has totally failed.

The registry data sources typically have a compression of up to 50%, which is not too surprising.

The compression is done using zlib.  The compression is performed on the last 32K of raw data from the given source (each source has it's own cache).  For performance reasons the data caching must be turned on manually.  I used a 32K cache because the zlib compression algorithm uses a 32K sliding window as a dictionary lookup.