On Sat, May 30, 2020 at 11:44:55PM +0200, Gero Treuner wrote:
According to the documents available in the net, entropy is not
influenced by consuming random numbers. Entropy is used to contantly
(re)reseeding the PRNG, and if insufficient entropy is present, you
might get imperfect random numbers
Ian Collier wrote in
<20200530212040.gk1301...@cs.ox.ac.uk>:
|On Mon, May 25, 2020 at 04:24:41PM +0200, Oswald Buddenhagen wrote:
|> why not do something proper and use getentropy() instead?
|
|It's been previously suggested on here that a mail client shouldn't
|consume entropy from the system
Hi Kevin,
> I'm not thinking about performance issues, but about the use and possible
> misuse of entropy. I'm not even convinced it's appropriate for Message-ID,
> so I certainly wouldn't like to see it put in a generic function used for
> temp files and message part boundaries.
According to th
On Mon, May 25, 2020 at 04:24:41PM +0200, Oswald Buddenhagen wrote:
> why not do something proper and use getentropy() instead?
It's been previously suggested on here that a mail client shouldn't
consume entropy from the system each time it starts, because other
more important processes may want i
On Sat, May 30, 2020 at 07:57:13PM +0200, Gero Treuner wrote:
What are performance expectations and methods for measurement?
Generate random numbers alternating with context switch (to not run
purely CPU top-level caches) such as a kernel rwad/write calls?
Hi Gero,
I'm not thinking about perfo
Hi,
On Fri, May 29, 2020 at 03:33:28PM -0700, Kevin J. McCarthy wrote:
> On Fri, May 29, 2020 at 03:58:35PM -0400, Remco Rijnders wrote:
> I think your comments in make a good case for not
> putting crypto-level randomization into a PRNG function, and I would like to
> think about it before movin
On Fri, May 29, 2020 at 03:58:35PM -0400, Remco Rijnders wrote:
On Mon, May 25, 2020 at 09:28:30AM -0700, Kevin wrote in
<20200525162830.gd1...@afu.lan>:
Remco, sorry I missed a few of those issues. In general you'll want
to follow the pattern of other files:
...
Got it (I hope)!
I have made
On Mon, May 25, 2020 at 09:28:30AM -0700, Kevin wrote in
<20200525162830.gd1...@afu.lan>:
Remco, sorry I missed a few of those issues. In general you'll want
to follow the pattern of other files:
...
Got it (I hope)!
I have made the necessary changes in message
<20200529195152.5925-1-re...@w
On Mon, May 25, 2020 at 10:04:40AM -0400, Remco Rijnders wrote:
Having made these changes, I get build errors of the kind:
Remco, sorry I missed a few of those issues. In general you'll want to
follow the pattern of other files:
* Your mutt_random.h should have #defines to prevent double inc
On Mon, May 25, 2020 at 04:24:41PM +0200, Oswald wrote in
<20200525142441.GC855843@ugly>:
Well, the idea for z4 is really to pick another seed than any other
user running mutt on the same system would have.
every process gets its own address space, so it will be the same in
each process, unless
On Mon, May 25, 2020 at 09:05:21AM -0400, Remco Rijnders wrote:
On Sun, May 24, 2020 at 06:49:03PM -0700, Kevin wrote in
<20200525014903.ga1...@afu.lan>:
+ z1 = ((u_int32_t) tv.tv_sec << 20) | tv.tv_usec;
+ z2 = getpid();
+ z3 = getppid();
+ z4 = (intptr_t) &z4;
+}
Comments on the seed choi
On Sun, May 24, 2020 at 06:49:03PM -0700, Kevin wrote in
<20200525014903.ga1...@afu.lan>:
diff --git a/mutt_random.h b/mutt_random.h
+#include
+#include
+#include
+#include
Mutt traditionally puts these inside the .c file. So I'd prefer to
see them moved there.
+extern void mutt_to_
On Mon, May 25, 2020 at 08:02:54AM +0200, Petr wrote in
<20200525060254.ga3...@album.bayer.uni.cx>:
Software distributors are not happy seeing various software carrying its own
cryptographic code. Could you please keep using the system-provided functions
if available?
Hi Petr,
Thank you for yo
On Sun, May 24, 2020 at 06:49:03PM -0700, Kevin wrote in
<20200525014903.ga1...@afu.lan>:
On Sun, May 24, 2020 at 04:59:24PM -0400, Remco Rijnders wrote:
By implementing the LFSR113 function by Pierre L'Ecuyer mutt gets a fast
and high quality PRNG that, given the same seeds, results in the same
On Sun, May 24, 2020 at 04:59:24PM -0400, Remco Rijnders wrote:
> When mutt needs a random number (for example for naming the tmp files or
> generating a boundary for MIME attachments) it currently uses different
> implementation specific functions: random() and either lrand48() or rand()
> are used
On Sun, May 24, 2020 at 04:59:24PM -0400, Remco Rijnders wrote:
By implementing the LFSR113 function by Pierre L'Ecuyer mutt gets a fast
and high quality PRNG that, given the same seeds, results in the same
output no matter the environment mutt is running on.
I'm not knowledgeable about PRNGs.
Makefile.am | 3 ++-
configure.ac | 1 -
Please note that I am not comfortable enough with autotools to be
certain if I did this the correct way (configure.ac) and also my
change to the Makefile might be sub optimal, I am not sure.
Cheers,
Remco
17 matches
Mail list logo
