[Feature request (DONE)] Fill random

[fungshen85]

Please I suggest fill random data option. This enhanced with option many pass for clean data secure.

[jovibor]

It's definitely a worthwhile idea, i also had it in mind previously.
The true random data though might be tricky to get (or slow).
Will think how to better implement it, in the next release(s).

[datasynergyuk]

This is a good idea. I would suggest two modes: (a) Fast using the C random number generator and (b) High entropy using something like: CryptGenRandom. I am tempted to add it myself to the Fill dialog. This would mean it needed to use MODIFY_OPERATION or possibly even a new EHexModifyMode type?

[jovibor]

I am tempted to add it myself to the Fill dialog.

You are welcome. A few notes though:

• "Fill with data" dialog must be redesigned for this task, at the moment it is very simple
• New EHexModifyMode enum member must be added, something like MODIFY_RANDOM
• CryptGenRandom function is deprecated and therefore should not be used.

I'm not sure about high cryptography here, is it really worth efforts in such simple domain? Maybe some simple rand would be enough?
As for high entropy, the std::random_device along with std::mt19937 must be used. But if we are talking about any big data chunks (say 4GB), a random data generation for such sizes will most likely be quite slow.

[jovibor]

This feature was implemented in 2a51d4f.

[datasynergyuk]

Thank you. I was still thinking about how to implement this.

Please can I suggest a further "Fill random quick (but good enough)" option that either re-cycled the same random data or used rand(). The current method is great but, as you predicted, quite slow.

[jovibor]

Make sure you're testing Release mode. In Debug it's indeed quite slow.

If it's still slow for you, then my suggestion is: change underlying rand method in the code to what you think is appropriately fast, and profile the speed diff.
If it's gonna be at least few times faster than the current approach I could then check-it-in.

[datasynergyuk]

Thank you. That was, as ever, excellent advice. You are correct, the debug build is incredibly slow. The results below are for a release build:

1. Fill file with fixed data: 186MB/s
2. Fill file with random data (existing algorithm): 69MB/s

*All tests done on same hardware with a 4GB test file. Each test repeated 4 times, first test ignored and subsequent 3 tests averaged.

I would suggest an additional "Quick but good enough" random fill. This could fill the buffer once and then recycle it. The result should be very similar to first case above and almost 3x faster than the current "More random but slower" method. Provided the buffer was reasonably large, the result would still be random enough for most everyday purposes.

[datasynergyuk]

This feature was fully implemented in 37aa49e. This could be closed now.