On Wednesday, July 8, 2015 at 4:50:11 PM UTC-4, jean-pierre.muench wrote: > > IMO, don't change RandomNumberGenerator. > OK, fair enough.
Am 08.07.2015 um 17:26 schrieb Jeffrey Walton: > > Testing of RandomNumberGenerator::GenerateWord32 revealed a bug in > GenerateBlock. > > GenerateBlock calls GenerateIntoBufferedTransformation. > GenerateIntoBufferedTransformation, in turn, calls, GenerateBlock. Ad > infinitum. > > This is by design, as far as I can tell. > But the thing that has always troubled me is, one (or both) are not pure virtuals. > > This patch fixes the circularity by calling OS_GenerateRandomBlock using > the OS's default entropy pool for userspace in a non-blocking mode. > > We already agreed that using "plain" OS's RNG isn't something we don't > want, so we should step away from providing it. > Furthermore the RNG class by itself *is supposed to be non-working*. It > is like an abstract base class which may be used with lower-level > implementations like X917 or RandomPool. > > > Another way to address t is to have GenerateIntoBufferedTransformation > throw an Exception with type set to NOT_IMPLEMENTED. But I think that > course will be less useful. > > This class by itself isn't intended for direct usage, without real > underlying primitives, so this would be the better choice to emphasize to > use a properly implemented class. > OK. Another option is to make GenerateIntoBufferedTransformation a pure virtual. > > Any comments or suggestions? > > I'll give a short answer on what I think is the rationale behind the > behavior you discovered. > > The RNG class has a problem: It needs to provide two basic interfaces for > random number generation. Everything else is built on these two functions. > So what to do? Make both virtual? This is unnecessary, an implementor would > likely only implement one of them, so why force him to write a wrapper > himself? > > The design choice behind this "bug" seems to be, that an implementor can > choose whether to implement GenerateBlock() or to implement > GenerateIntoBufferedTransformation(). If he implements either of those, > he's fine. If he misses to implement any of these he'll see his test > failing and will notice that he has to implement one of them. > > So please leave it as it is right now (5.6.2) > OK, will do. Jeff -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
