On Thursday, 20 March 2014 at 01:32:41 UTC, Chris Williams wrote:
Any chance that you could describe them? I was about to resume porting the dcrypt library into Phobos, and had intended to flip the classes into structs, to match what the rest of the library was doing.


I think there's a good case for a std.random2.crypto module that contains RNGs that are specifically suitable for cryptography. That said I think the bar here has to be set VERY high, which is why I didn't even begin working on it yet. It has been argued by some that where crypto in Phobos is concerned, we shouldn't take community contributions but we should hire security experts to write the functionality for us.

Anyway, let's keep in touch about this and discuss how we could support one another's efforts.

About the issues with value-type RNGs (as monarch_dodra says, it's not structs vs. classes per se, as you can implement reference types via structs; it's just more finnicky to do so), probably the best starting point is to read through the various bugs that have been reported as a result of this:
https://d.puremagic.com/issues/show_bug.cgi?id=7067
https://d.puremagic.com/issues/show_bug.cgi?id=7936
https://d.puremagic.com/issues/show_bug.cgi?id=8247
https://d.puremagic.com/issues/show_bug.cgi?id=10322

Although some of these are marked as fixed, the fixes are pretty unpleasant and are workarounds rather than solutions of the underlying problem. It may look like only a few issues, but the implications are nasty. We had extensive discussions about this over the last year:
http://forum.dlang.org/thread/mailman.259.1357667544.22503.digitalmar...@puremagic.com
http://forum.dlang.org/thread/mailman.1017.1370879340.13711.digitalmar...@puremagic.com
http://forum.dlang.org/thread/mailman.1157.1371497540.13711.digitalmar...@puremagic.com
http://forum.dlang.org/thread/mailman.1209.1371565034.13711.digitalmar...@puremagic.com
http://forum.dlang.org/thread/mailman.443.1377369357.1719.digitalmar...@puremagic.com
http://forum.dlang.org/thread/5218fd04.8040...@webdrake.net

The bottom line is that implementing your RNGs as classes automatically gets you out of the worst of these traps by giving you reference semantics from the get-go. Whether there are other problems that arise from this that make you prefer another design is a question you'll have to answer for yourself -- someone may yet come up with an objection that shows my current design is a Very Bad Idea ;-)

Anyway, the example with rndGen.take(10).writeln that monarch_dodra gave is probably the best argument one can make. Imagine a cryptographic application where you're generating (supposedly) two different sets of random data, and because of an unintended value-type copy like this they turn out to be identical. Insecure much? :-)

Reply via email to