On 12/06/2015 00:38, Matthew Flatt wrote:
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.
In my understanding the pseudo random number generator is deterministic.
That means for the same input seed /random/ will always return the same
value. This is why one usually has to set a new state for each call of
random.
In the current implementation I get a one byte value from the entropy
pool via the device "/dev/urandom". One byte has 256 possibilities. Now
that already is true randomness but I have to map it onto a character
set of 65 possible output characters. This is why I put the true
randomness byte into the seed and then I call random to do the mapping
correctly. There is almost four times the entropy of the output
possibilities but random still creates that bias in the range from 0 to 255.
A decade ago or more I had a short look at chaos functions or unstable
functions. The only I was able to understand at that time started to
become unstable or chaotic only after some distance away from the
origin. For small numbers it was - well, I can't remember exactly -
almost linear or sine like ...
Racket's /random/ seems to work well with the current values of the
system clock in microseconds and the seed input space is 0 to (expt 2
31) which is the same as positive signed integers on 32 bit systems
which is the range of current-exact-milliseconds or however it was called.
But to be able to use true randomness with Racket's random and to avoid
the capital letter G bias I would have to do the bit fiddling of the
input state myself by either shifting values or by adding or subtracting
it to or from the current exact milliseconds ...
Does using `vector->pseudo-random-generator!` in place of `random-seed`
solve the problem?
I do not know - I am not going to recreate a chaotic function that makes
best use of its input. Perhaps I should - perhaps I should do it know
instead of just relying on the FSF and Guile but the source code of my
make-passwd is already in the public domain. Anyone can improve it.
--
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.
