random library

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

random library

Kazu Yamamoto (山本和彦)
Hello,

I'm preparing for a major release of the dns package version 3.0.0.
https://github.com/kazu-yamamoto/dns/issues/88

Before the release, I would like to replace the random package since
it is slow.  I'm looking for a random library which is
- fast
- thread-safe (good for concurrent use)

Any recommendations?

// Kazu
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

David Johnson
I've heard good things about mwc-random (https://github.com/bos/mwc-random)

On Tue, Oct 10, 2017 at 5:48 PM, Kazu Yamamoto <[hidden email]> wrote:
Hello,

I'm preparing for a major release of the dns package version 3.0.0.
https://github.com/kazu-yamamoto/dns/issues/88

Before the release, I would like to replace the random package since
it is slow.  I'm looking for a random library which is
- fast
- thread-safe (good for concurrent use)

Any recommendations?

// Kazu
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.



--
Cell: 1.630.740.8204

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

Kazu Yamamoto (山本和彦)
Hi David,

Thank you for your reply.

> I've heard good things about *mwc-random* (https://github.com/bos/mwc-random
> )

Are there any example code to use mwc-random safely from multiple
threads?

// Kazu
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

William Yager
The best way to generate random values in multiple threads is to safely split your random generator every time you fork.

In the case of mwc-random, it looks like you will want to do something like 

gen' <- initialize =<< (uniformVector gen 32 :: IO (Vector Word32))
forkIO $ ... gen'
... gen

There is no good reason to share RNG state across threads. Just use a separate RNG state for every thread. This is inherently thread-safe and more performant.

If you're forking very frequently, you will want to benchmark the effect of using a more efficient vector type (i.e. Vector.Unboxed instead of Vector) or fewer elements during initialization. 



On Tue, Oct 10, 2017 at 9:06 PM, Kazu Yamamoto <[hidden email]> wrote:
Hi David,

Thank you for your reply.

> I've heard good things about *mwc-random* (https://github.com/bos/mwc-random
> )

Are there any example code to use mwc-random safely from multiple
threads?

// Kazu
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

Viktor Dukhovni
In reply to this post by Kazu Yamamoto (山本和彦)

> On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) <[hidden email]> wrote:
>
> Before the release, I would like to replace the random package since
> it is slow.  I'm looking for a random library which is
> - fast
> - thread-safe (good for concurrent use)
>
> Any recommendations?

Just to make it more interesting, I should mention that the RNG
should be not just statistically random, but should in fact be
crypto random (resist predictability through cryptanalysis when
properly seeded).

So indeed there are two more issues here:

 - Securely seeding the RNG (likely using the OS API for
   random seeds, and/or the RDSEED/RDRAND instructions on
   Intel CPUs), IIRC we can that from cryptonite, I hope
   at a reasonable cost.

 - Choosing a suitable DRBG based on the seed.  Likely again
   something from cryptonite.

Some time back I posted to the cryptography list about the
soundness of relying on RDRAND in cryptonite's RNG (uses
it instead of /dev/urandom and the like when available).
The rough consensus IIRC was not rely solely on RDRAND.
I never went back to write a PR to address that...

http://www.metzdowd.com/pipermail/cryptography/2016-November/thread.html#30859

--
        Viktor.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

Thomas DuBuisson
The hash drbg from the drbg package should meet your needs. Deterministic, pure Haskell except the actual hash function.

On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" <[hidden email]> wrote:

> On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) <[hidden email]> wrote:
>
> Before the release, I would like to replace the random package since
> it is slow.  I'm looking for a random library which is
> - fast
> - thread-safe (good for concurrent use)
>
> Any recommendations?

Just to make it more interesting, I should mention that the RNG
should be not just statistically random, but should in fact be
crypto random (resist predictability through cryptanalysis when
properly seeded).

So indeed there are two more issues here:

 - Securely seeding the RNG (likely using the OS API for
   random seeds, and/or the RDSEED/RDRAND instructions on
   Intel CPUs), IIRC we can that from cryptonite, I hope
   at a reasonable cost.

 - Choosing a suitable DRBG based on the seed.  Likely again
   something from cryptonite.

Some time back I posted to the cryptography list about the
soundness of relying on RDRAND in cryptonite's RNG (uses
it instead of /dev/urandom and the like when available).
The rough consensus IIRC was not rely solely on RDRAND.
I never went back to write a PR to address that...

http://www.metzdowd.com/pipermail/cryptography/2016-November/thread.html#30859

--
        Viktor.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

jpaugh
All,

Interesting library! Here's a link: http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html

Thomas,

In the linked docs, there's a claim that Hash DRBG is the fastest cryptographically secure RNG on Hackage. Do you have a link to the benchmark results, or perhaps some updated ones? Unlike Viktor, I'm interested in less secure applications, but if the performance is good, it might be worth switching from the defacto random package.

Thanks,
Jonathan

On October 10, 2017 10:23:14 PM CDT, Thomas DuBuisson <[hidden email]> wrote:
The hash drbg from the drbg package should meet your needs. Deterministic, pure Haskell except the actual hash function.

On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" <[hidden email]> wrote:

> On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) <[hidden email]> wrote:
>
> Before the release, I would like to replace the random package since
> it is slow.  I'm looking for a random library which is
> - fast
> - thread-safe (good for concurrent use)
>
> Any recommendations?

Just to make it more interesting, I should mention that the RNG
should be not just statistically random, but should in fact be
crypto random (resist predictability through cryptanalysis when
properly seeded).

So indeed there are two more issues here:

 - Securely seeding the RNG (likely using the OS API for
   random seeds, and/or the RDSEED/RDRAND instructions on
   Intel CPUs), IIRC we can that from cryptonite, I hope
   at a reasonable cost.

 - Choosing a suitable DRBG based on the seed.  Likely again
   something from cryptonite.

Some time back I posted to the cryptography list about the
soundness of relying on RDRAND in cryptonite's RNG (uses
it instead of /dev/urandom and the like when available).
The rough consensus IIRC was not rely solely on RDRAND.
I never went back to write a PR to address that...

http://www.metzdowd.com/pipermail/cryptography/2016-November/thread.html#30859

--
        Viktor.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

William Yager
In reply to this post by Thomas DuBuisson


On Tue, Oct 10, 2017 at 11:23 PM, Thomas DuBuisson <[hidden email]> wrote:
The hash drbg from the drbg package should meet your needs. Deterministic, pure Haskell except the actual hash function.


I was looking at this recently; may I ask why drbg and crypto-api even bother to expose the possibility of CSPRNGs "running out" of entropy? This is not thought to be a concern on any cryptographically sound primitive, and it substantially complicates both the implementation and the user-facing API. The currently selected reseed interval of 2^48 is already large enough that it might as well not be there; it's too large to provide forward secrecy and almost large enough that you'll never hit it. 

If you're looking for a more reputable source for this claim, there is a wealth of literature on the current best practices for OS-level CSPRNGs. In particular, both Linux (via the new getrandom(2) API) and the BSDs (via the block device API which has done the right thing for a long time) now have the behavior of waiting for ~256 bits of initial entropy and then providing unlimited random bytes forever without ever blocking or requiring a reseed. 

Might I suggest in a future revision of the drbg/crypto-api libraries dropping all mentions of "Either" from the CryptoRandomGen typeclass API, except maybe "newGen"? I think this would make your job a lot easier *and* make the library a lot easier to consume (e.g. via RandT).

--Will



_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

Dominic Steinitz-2
In reply to this post by Kazu Yamamoto (山本和彦)
No-one should be using the de facto random package. It is slow and produces surprising results.

I think one of the posters suggested using mwc-random and splitting by using a different seed. Although mwc-random has reasonably good properties, there is no guarantee about how correlated the various streams of random numbers will be. QuickCheck uses tf-random to avoid such problems. There is also a version of SplitMix https://hackage.haskell.org/package/splitmix but I don’t think this has been heavily road-tested.

But in this case, cryptographically secure randomness is required so I would follow Thomas’ suggestion.

PS I just noticed my spellchecker changed defacto to defect! Perhaps AI is taking over.

All,

Interesting library! Here's a link: http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html

Thomas,

In the linked docs, there's a claim that Hash DRBG is the fastest cryptographically secure RNG on Hackage. Do you have a link to the benchmark results, or perhaps some updated ones? Unlike Viktor, I'm interested in less secure applications, but if the performance is good, it might be worth switching from the defacto random package.

Thanks,
Jonathan

On October 10, 2017 10:23:14 PM CDT, Thomas DuBuisson <[hidden email]> wrote:
The hash drbg from the drbg package should meet your needs.
Deterministic,
pure Haskell except the actual hash function.

On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" <[hidden email]>
wrote:


On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) <[hidden email]>
wrote:

Before the release, I would like to replace the random package
since
it is slow.  I'm looking for a random library which is
- fast
- thread-safe (good for concurrent use)

Any recommendations?

Just to make it more interesting, I should mention that the RNG
should be not just statistically random, but should in fact be
crypto random (resist predictability through cryptanalysis when
properly seeded).

So indeed there are two more issues here:

- Securely seeding the RNG (likely using the OS API for
 random seeds, and/or the RDSEED/RDRAND instructions on
 Intel CPUs), IIRC we can that from cryptonite, I hope
 at a reasonable cost.

- Choosing a suitable DRBG based on the seed.  Likely again
 something from cryptonite.

Some time back I posted to the cryptography list about the
soundness of relying on RDRAND in cryptonite's RNG (uses
it instead of /dev/urandom and the like when available).
The rough consensus IIRC was not rely solely on RDRAND.
I never went back to write a PR to address that...

http://www.metzdowd.com/pipermail/cryptography/2016-
November/thread.html#30859

--
      Viktor.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

Thomas DuBuisson
In reply to this post by William Yager
> I was looking at this recently; may I ask why drbg and crypto-api even
> bother to expose the possibility of CSPRNGs "running out" of entropy?

Because most standards discuss this possibility and my decisions at
the time were motivated by trying to make those implementations as
much of a mindless "translate English to Haskell" job as possible.

> This is not thought to be a concern on any cryptographically sound primitive

The primitive's soundness doesn't have anything to do with the period.
We can construct a sound cipher with small block size and claim the
counter mode of this cipher is a DRBG that is both secure and with a
small period.

> , and
> it substantially complicates both the implementation and the user-facing
> API.

The implementations are not substantially harder.  For the users I had
begun moving to exceptions with separate `.Pure` and `.Exceptions`
modules.  The API is all a bit long in the tooth and could stand for
me to spend some time on it though.

> The currently selected reseed interval of 2^48 is already large enough
> that it might as well not be there; it's too large to provide forward
> secrecy

Again, this is unrelated.  The instantiated Hash and HMAC DRBGs both
have forward secrecy and large intervals.

> and almost large enough that you'll never hit it.

Yes! That is the convincing argument right there.  The fact that no
user actually cares (beyond getting an exception instead of unsafe
operation) or will ever hit such a bound is rather important.

> Might I suggest in a future revision of the drbg/crypto-api libraries
> dropping all mentions of "Either" from the CryptoRandomGen typeclass API,
> except maybe "newGen"? I think this would make your job a lot easier *and*
> make the library a lot easier to consume (e.g. via RandT).

Well my job is easiest doing nothing.  But yes, making it nice for
users would be good.  I've been meaning to give these packages some
more attention and I'll take this as motivation.

-Thomas
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: random library

Thomas DuBuisson
In reply to this post by jpaugh
Jonathan,

The full claim is:

> As of 1July2014 this remains the fastest cryptographic RNG on hackage that has been ran against known answer tests.

Many other packaged generators are off-the-cuff inventions of the
programmer - IIRC the two designs I saw most were 1. Pick a random IV
or counter, generate some data with a block cipher, repeat and 2. Just
run a stream cipher like AES-CTR (so, no forward secrecy).  The
developers are often people who's knowledge I have faith in but the
decision is too serious to make such designs lightly.

The only package I knew of at the time that tried to implement a
standard that included KATs (unit tests) was my DRBG package w/ tests
for the Hash generator and HMAC.  In this case, the Hash generator is
notably faster than HMAC.

As for the performance of this and other generators, I did some
benchmarking now 4 years ago:
http://tommd.github.io/posts/RNG-Bench.html   N.B. I intentionally did
not discuss security in that post.  Many people want a standard, some
just don't care about forward secrecy, others won't touch RDRAND with
a ten foot pole.  All fine, but too many dimensions for me to want to
talk about in a blog post.

Cheers,
Thomas

On Tue, Oct 10, 2017 at 8:46 PM,  <[hidden email]> wrote:

> All,
>
> Interesting library! Here's a link:
> http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html
>
> Thomas,
>
> In the linked docs, there's a claim that Hash DRBG is the fastest
> cryptographically secure RNG on Hackage. Do you have a link to the benchmark
> results, or perhaps some updated ones? Unlike Viktor, I'm interested in less
> secure applications, but if the performance is good, it might be worth
> switching from the defacto random package.
>
> Thanks,
> Jonathan
>
>
> On October 10, 2017 10:23:14 PM CDT, Thomas DuBuisson
> <[hidden email]> wrote:
>>
>> The hash drbg from the drbg package should meet your needs. Deterministic,
>> pure Haskell except the actual hash function.
>>
>> On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" <[hidden email]> wrote:
>>>
>>>
>>> > On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) <[hidden email]>
>>> > wrote:
>>> >
>>> > Before the release, I would like to replace the random package since
>>> > it is slow.  I'm looking for a random library which is
>>> > - fast
>>> > - thread-safe (good for concurrent use)
>>> >
>>> > Any recommendations?
>>>
>>> Just to make it more interesting, I should mention that the RNG
>>> should be not just statistically random, but should in fact be
>>> crypto random (resist predictability through cryptanalysis when
>>> properly seeded).
>>>
>>> So indeed there are two more issues here:
>>>
>>>  - Securely seeding the RNG (likely using the OS API for
>>>    random seeds, and/or the RDSEED/RDRAND instructions on
>>>    Intel CPUs), IIRC we can that from cryptonite, I hope
>>>    at a reasonable cost.
>>>
>>>  - Choosing a suitable DRBG based on the seed.  Likely again
>>>    something from cryptonite.
>>>
>>> Some time back I posted to the cryptography list about the
>>> soundness of relying on RDRAND in cryptonite's RNG (uses
>>> it instead of /dev/urandom and the like when available).
>>> The rough consensus IIRC was not rely solely on RDRAND.
>>> I never went back to write a PR to address that...
>>>
>>>
>>> http://www.metzdowd.com/pipermail/cryptography/2016-November/thread.html#30859
>>>
>>> --
>>>         Viktor.
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: haskell-cafe brown out [Was: random library]

Dominic Steinitz-2
In reply to this post by Dominic Steinitz-2
I get a daily digest from the mailing list and then cut out the bit that seemed relevant fwiw. Well done for caring about mailing lists :)

> On 11 Oct 2017, at 17:28, Ian Zimmerman <[hidden email]> wrote:
>
> On 2017-10-11 13:50, [hidden email] wrote:
>
>>> Interesting library! Here's a link:
>>> http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html
>>> <http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html>
>>>
>>> Thomas,
>>>
>>> In the linked docs, there's a claim that Hash DRBG is the fastest
>>> cryptographically secure RNG on Hackage. Do you have a link to the
>>> benchmark results, or perhaps some updated ones? Unlike Viktor, I'm
>>> interested in less secure applications, but if the performance is
>>> good, it might be worth switching from the defacto random package.
>>>
>>> Thanks, Jonathan
>
>> No-one should be using the de facto random package. It is slow and
>> produces surprising results.
>>
>> I think one of the posters suggested using mwc-random and splitting by
>> using a different seed. Although mwc-random has reasonably good
>> properties, there is no guarantee about how correlated the various
>> streams of random numbers will be. QuickCheck uses tf-random to avoid
>> such problems. There is also a version of SplitMix
>> https://hackage.haskell.org/package/splitmix
>> <https://hackage.haskell.org/package/splitmix> but I don’t think this
>> has been heavily road-tested.
>>
>> But in this case, cryptographically secure randomness is required so I
>> would follow Thomas’ suggestion.
>>
>> PS I just noticed my spellchecker changed defacto to defect! Perhaps
>> AI is taking over.
>
> Hello, may I ask how exactly you posted the above message?
>
> Your message has no threading headers (In-Reply-To or References), but I
> _think_ I never received the message to which you appear to be reacting
> (that one by "Jonathan").  I cannot prove it beyond doubt because of the
> missing headers.  Was "Jonathan"'s message posted on the haskell-cafe
> mailing list at all?  Or what else is going on here?
>
> Ian, who cares about his mailing lists
>
> --
> Please don't Cc: me privately on mailing lists and Usenet,
> if you also post the followup to the list or newsgroup.
> Do obvious transformation on domain to reply privately _only_ on Usenet.

Dominic Steinitz
[hidden email]
http://idontgetoutmuch.wordpress.com

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: haskell-cafe brown out [Was: random library]

Ian Zimmerman-2
On 2017-10-14 14:09, [hidden email] wrote:

> > Your message has no threading headers (In-Reply-To or References),
> > but I _think_ I never received the message to which you appear to be
> > reacting (that one by "Jonathan").  I cannot prove it beyond doubt
> > because of the missing headers.  Was "Jonathan"'s message posted on
> > the haskell-cafe mailing list at all?  Or what else is going on
> > here?

> I get a daily digest from the mailing list and then cut out the bit
> that seemed relevant fwiw. Well done for caring about mailing lists :)

[replying to list because that's what Dominic did, I wouldn't otherwise]

Never mind, Jonathan's message was in my spam box.  (I'll look into the
cause of _that_ shortly).

Some MUAs are smart enough to handle the replying-to-digest case and
insert the proper threading headers.  They are unfortunately (?) not the
same ones as those smart enough to draw nice GUI sprites :P  Maybe you
can investigate that some time when you're bored.

But in general I have to say haskell.org lists are _a lot_ cleaner now
than a few years ago when pretty much _every_ thread was broken due to
ppl posting via shmooglegroups.

--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Your haskell-cafe message [Was: random library]

jpaugh
In reply to this post by jpaugh
Ian,

Thanks for the note. I work for a secondary school, so that explains the block. I'll keep that in mind, and send mail from home.

Thanks,
Jon

On October 14, 2017 12:29:03 PM CDT, Ian Zimmerman <[hidden email]> wrote:
On 2017-10-10 22:46, [hidden email] wrote:

Interesting library! Here's a link:
http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html

The address from which you posted this is listed by spamhaus:

ahiker!2 itz$ rblcheck 172.56.6.158
172.56.6.158 not listed by sbl.spamhaus.org
172.56.6.158 listed by xbl.spamhaus.org
172.56.6.158 listed by pbl.spamhaus.org
172.56.6.158 not listed by bl.spamcop.net
172.56.6.158 not listed by psbl.surriel.com
172.56.6.158 not listed by dul.dnsbl.sorbs.net

This often happens when people post from cafes and similar, and if this
is the case here not much can be done, unfortunately - other than
perhaps trying a different cafe next time :-)

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.