On 5/24/2014 5:19 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 24/05/14 19:46, Nick Sabalausky via Digitalmars-d wrote:
An initial PR for Hash_DRBG being struct-based and directly part of
std.random
I think that's up to you. I don't want to hold you back here, but
equally, I feel
On 5/23/2014 3:43 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
OK, so let's run with the idea that at some point crypto RNGs will be a
submodule of std.random.
So to recap my understanding of it:
An initial PR for Hash_DRBG being struct-based and directly part of
std.random, and
On 24/05/14 19:46, Nick Sabalausky via Digitalmars-d wrote:
An initial PR for Hash_DRBG being struct-based and directly part of
std.random
I think that's up to you. I don't want to hold you back here, but equally, I
feel that crypto functionality probably should be prototyped in an
Hi Nick,
Short reply because I think things are converging pretty well decision-wise :-)
because crypto RNGs' .popFront() is of necessity going to be non-pure.)
To make sure I understand (it seems my understanding of D's pure isn't quite as
strong as I'd thought): It cannot be pure
On 5/23/2014 3:04 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
Hi Nick,
Short reply because I think things are converging pretty well
decision-wise :-)
because crypto RNGs' .popFront() is of necessity going to be non-pure.)
To make sure I understand (it seems my understanding of
On 23/05/14 21:38, Nick Sabalausky via Digitalmars-d wrote:
Oh, right. For some reason I was thinking front, not popFront. My bad.
Actually it's probably irrelevant in your case anyway, isn't it, because you'll
be outputting raw binary data to a provided output range ... ?
Well, I don't
On 12/05/14 20:17, Nick Sabalausky via Digitalmars-d wrote:
On 5/11/2014 8:16 AM, Joseph Rushton Wakeling via Digitalmars-d wrote: On
11/05/14 05:58, Nick Sabalausky via Digitalmars-d wrote:
The seed doesn't need to be compromised for synchronized RNGs to fubar
security.
Before we go
On 5/22/2014 5:01 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 12/05/14 20:17, Nick Sabalausky via Digitalmars-d wrote:
Yea, doesn't necessarily mean class, but if it is made a reference
type then
class is likely the best option. For example, I'd typically regard
struct* in a
D API
On 5/11/2014 8:16 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 11/05/14 05:58, Nick Sabalausky via Digitalmars-d wrote:
The seed doesn't need to be compromised for synchronized RNGs to fubar
security.
Before we go onto the detail of discussion, thanks very much for the
extensive
On 11/05/14 05:58, Nick Sabalausky via Digitalmars-d wrote:
The seed doesn't need to be compromised for synchronized RNGs to fubar security.
Before we go onto the detail of discussion, thanks very much for the extensive
explanation. I was slightly worried that my previous email might have
On 09/05/14 02:42, Nick Sabalausky via Digitalmars-d wrote:
There can technically be multiple instances, but yea, they're all effectively
tied together. However, I'm leaning towards the belief that's correct behavior
for a RNG. It's *definitely* correct for a crypto RNG - you certainly wouldn't
On 5/10/2014 12:34 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 09/05/14 02:42, Nick Sabalausky via Digitalmars-d wrote:
There can technically be multiple instances, but yea, they're all
effectively
tied together. However, I'm leaning towards the belief that's correct
behavior
On Friday, 9 May 2014 at 00:43:10 UTC, Nick Sabalausky wrote:
On 5/8/2014 5:29 PM, Joseph Rushton Wakeling via Digitalmars-d
wrote:
That seems a problematic fix for me -- doesn't it mean that
there can
only ever be one instance of any individual RNG?
There can technically be multiple
On Friday, 9 May 2014 at 00:43:10 UTC, Nick Sabalausky wrote:
As for ordinary non-crypto RNGs, I honestly can't imaging any
purpose for reliably generating the same values other than
playing back a previous sequence. But if that's what you
want, then IMO it's better to record the sequence of
On 5/4/2014 4:08 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
I should also be thanking you -- this reminded me that I needed to make
some key changes to my std.random2 proposal, including this stricter
isUniformRNG template:
On 08/05/14 19:18, Nick Sabalausky via Digitalmars-d wrote:
Some good looking stuff in there. The separation is a nice improvement, and
having a shuffle is something we could certainly use.
Thanks! :-)
There is already a shuffle function in the existing std.random, but it's called
On 5/8/2014 5:29 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 08/05/14 19:18, Nick Sabalausky via Digitalmars-d wrote:
Some good looking stuff in there. The separation is a nice
improvement, and
having a shuffle is something we could certainly use.
Thanks! :-)
There is already a
On 5/4/2014 3:26 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 04/05/14 20:56, Nick Sabalausky via Digitalmars-d wrote:
So I think it's probably safe to figure this is a uniform distribution
unless
some expert chimes in and says otherwise.
Thanks for the help.
You're very welcome.
On 5/7/2014 4:06 PM, Nick Sabalausky wrote:
// The algorithm specifically supports generating
// arbitrary lengths at once, so can also do:
HashDRBGStream!uint randStream;
Oops, that's supposed to be:
HashDRBGStream!() randStream;
//aka:
// HashDRBGStream!(SHA512, D Crypto RNG) randStream;
On Wednesday, 7 May 2014 at 20:11:13 UTC, Nick Sabalausky wrote:
HashDRBGStream!() randStream;
//aka:
// HashDRBGStream!(SHA512, D Crypto RNG) randStream;
The stream version isn't a range and only supports filling a
provided ubyte[] buffer. So no element type.
Shouldn't that take an ubyte
On Wednesday, 7 May 2014 at 21:01:20 UTC, David Nadlinger wrote:
Shouldn't that take an ubyte output range instead?
Erm, scrap that, wasn't thinking.
David
On 5/7/2014 5:09 PM, David Nadlinger wrote:
On Wednesday, 7 May 2014 at 21:01:20 UTC, David Nadlinger wrote:
Shouldn't that take an ubyte output range instead?
Erm, scrap that, wasn't thinking.
Actually, maybe it should, even if only as an option. Unless I'm the one
not thinking now...?
On 04/05/14 04:03, Nick Sabalausky via Digitalmars-d wrote:
In std.random, is the isUniformRNG intended to determine whether the given
type is *some* RNG or just a *specific* form of RNG? Because I don't see any
isRNG that's more general.
Yes, it is meant to denote that the type is a _uniform_
On 5/4/2014 3:47 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
About a more general isRNG template: can you be more precise about
what you are interested in achieving with this? Generally speaking I
would find it rather dangerous to go passing around sources of
randomness without having
On 04/05/14 16:28, Nick Sabalausky via Digitalmars-d wrote:
On a general level, I'm trying to grok the whole intent of isUniformRNG and see
whether or not anything else may ever be needed in addition to isUniformRNG. I'm
not trying to push an isRNG, just trying to understand std.random's current
On 5/4/2014 11:38 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 04/05/14 16:28, Nick Sabalausky via Digitalmars-d wrote:
On a general level, I'm trying to grok the whole intent of
isUniformRNG and see
whether or not anything else may ever be needed in addition to
isUniformRNG. I'm
not
On 04/05/14 19:42, Nick Sabalausky via Digitalmars-d wrote:
Just a string of random bits. Effectively unsigned integers.
Ahh, OK. So in practice you can probably template it on an unsigned integral
type (which could include bool) and it'll just take the appropriate number of
bits from the
On 04/05/14 20:10, Joseph Rushton Wakeling via Digitalmars-d wrote:
Probably :-) Let's put it this way:
... we can always empirically verify the uniformity of the distribution :-)
On 5/4/2014 2:10 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 04/05/14 19:42, Nick Sabalausky via Digitalmars-d wrote:
Just a string of random bits. Effectively unsigned integers.
Ahh, OK. So in practice you can probably template it on an unsigned
integral type (which could
On 04/05/14 20:56, Nick Sabalausky via Digitalmars-d wrote:
So I think it's probably safe to figure this is a uniform distribution unless
some expert chimes in and says otherwise.
Thanks for the help.
You're very welcome. Keep me posted on how things go with your implementation!
:-)
On 5/4/2014 3:26 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 04/05/14 20:56, Nick Sabalausky via Digitalmars-d wrote:
So I think it's probably safe to figure this is a uniform distribution
unless
some expert chimes in and says otherwise.
Thanks for the help.
You're very welcome.
On 04/05/14 21:26, Joseph Rushton Wakeling via Digitalmars-d wrote:
On 04/05/14 20:56, Nick Sabalausky via Digitalmars-d wrote:
So I think it's probably safe to figure this is a uniform distribution unless
some expert chimes in and says otherwise.
Thanks for the help.
You're very welcome.
32 matches
Mail list logo
