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:
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:
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? :-)