At Wed, 10 Jun 2015 18:44:15 +0200, Michael Titke wrote: > On 10/06/2015 12:33, Michael Titke wrote: > > I changed from one OS to another and I was missing a simple feature: > > automatic password generation. To fill the gap with a Scheme I > > implemented such a generator as a command line tool respectively > > /crypto sweet/. > > > > After having read /SRFI 27: Sources of Random Bits/ I decided to > > implement my algorithm natively with /Guile 1.8/ and /Racket 6.1/. > > There is some portability of simple RnRS System Scheme programs: right > > now it seems that the "heritage" of the Scheme Shell (/scsh/) grants > > portability across UNIX/POSIX/SUS systems. > > > > Even when it comes to true randomness as perhaps generated by the > > noise in the low order magnitudes/bits of hardware sensors which is > > enhanced and accessible with the file system device entry > > "/dev/urandom" this simple System Scheme Script remains portable. > > Accessing entropy pools on other systems should be as easy - perhaps > > with the foreign function interface. > > > > With real entropy pools the need for the interface described by SRFI > > 27 vanishes almost completely. It's still a good idea to seed some > > randomizing function with real entropy before using it but randomizing > > functions do IMHO not constitute a domain of their own whereas SRFI 27 > > declares them to be. > > > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to racket-users+unsubscr...@googlegroups.com > > <mailto:racket-users+unsubscr...@googlegroups.com>. > > For more options, visit https://groups.google.com/d/optout. > The expressions used in this text might diverge significantly from usual > mathematical terminology. > But I didn't study maths at university ... > > There seems to be a strong bias in the /Racket/ version (three examples: > "G3GpGGGCuG3u", "GGIGYGGGI9GG", "mGGGGGCnF3G,") with a lot of capital > letter Gs so please don't use it in production environments. > This bias is that obvious because there neither is a further > permutation of the initial character sets nor an obfuscation of the > result. But this bias might mean that the procedure /random/ is not > (what I call) /holomorphic/: the procedure /random /does not "spread or > distribute the seed" across the destination space (one dimension with a > magnitude denoted by n). Filling all the 31 bits of the seed might > produce visually more appealing results but it could as well be as > strongly biased as the examples given. In my understanding of /random/ > as an /unstable function/ *the current behavior is **wrong* or I missed > some point about Racket's randomness. Right now it seems to have the > opposite effect of an unstable function: it seems to reduce the entropy > in the given example like a stabilizer where it should act as a > randomizer ... > > The other version does not have such an obvious bias but I have not yet > analyzed the "saturation / distribution" and other properties of the > resulting shared secrets. Right now I do not have the time to check this > and I don't want to file a bug report as long as I'm not sure about the > source of the bias.
I'm not sure I follow, but I think you're right to suggest an issue with `random-seed`. The space of inputs for `random-seed` is much smaller than the state of the random-number generator, and by repeatedly setting the seed that way, you're reducing the space of generated numbers; it makes sense that it would also bias the generated numbers in various. Does using `vector->pseudo-random-generator!` in place of `random-seed` solve the problem? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
