World: r3wp

We take several steps in various bits of REBOL.org system code to 
produce unique identifiers.

The code factors in not just now/time/precise but also things like:
-- user name
-- length? mold system
-- incoming IP address

But, ultimately, you cannot *guarantee* not to get an id clash that 
way. So (in cases where clashes matter), we also create a temporary 
file, id.tmp .... If that already exists, we generate a fresh id 
until we  get a unique one.   In the case of REBOL.org, the id.tmp 
files are deleted weekly, as a week old clash is not important.

Geomol, use RANDOM/SEED NOW/PRECISE (no /time and no to decimal!)

Gabriele, I'm afraid, that's not good enough. Try this:
>> loop 10 [random/seed now/precise print random 100]
28
28
28
28
28
28
28
28
28
28

While if I do it my way, I get this:

>> loop 10 [random/seed to decimal! now/time/precise print random 
100]
75
53
21
3
2
57
54
69
74
15

(I did it under OS X with version 2.7.6)

You could drop the seeding and just use random/secure
   loop 10 [prin [random/secure 100 " "]]
   99  22  67  18  31  6  54  80  94  24

What do random/secure do precisely? Does anyone know?

It claims to be a "cryptographically secure random".
That won't stop clashes though

http://www.rebol.com/docs/words/wrandom.html

What I'm after, is a secure way to produce a password, also in a 
webservice, that could be called many times each second. RANDOM/secure 
can produce the same output again and again, as can be seen with 
this:
>> loop 10 [random/seed now/precise prin [random/secure 100 ""]]
61 61 61 61 61 61 61 61 61 61

See the block as the webservice. So here it's not good to use random/seed. 
If I leave out random/seed, what then define the initial state of 
the random generator? I need to know this to figure out, if this 
is a secure way to produce a password or not.

As I suggested above, if it is a webservice, you can use other things 
in addition to the precise time:
-- caller's ip address
-- referer URL

They will vary between calls -- unless exactly the same incoming 
URL is processed at exactly the same moment....That's unlikely, even 
if someone is resetting the server's time.

Geomol, the problem with your  loop is that yuo have the random/seed 
in the loop. The random/seed is called once then make your loop with 
just the random or random/secure.

Edgar, I know that. My question is, what happens if no random/seed 
is used in a REBOL program?
My other question is, what does random/secure mean?

To illustrate my point, try create this rebol script (call it random.r 
or whatever) on you disk:

REBOL []

print random 100
ask "OK"


Now click it from the explorer in windows. I get the result 95 every 
time. That's not random!

I need to do something like Sunanda suggest. But before I do that, 
I would like to know, if I can do it in another way. And then it 
would be cool, if I learned, what exactly random/secure mean.

Generate pools of passwords, and store a counter to use when you 
need to re-seed and generate a new pool. That way you can generate 
them over a long period of time and just pull them as necessary.

Great idea! :-) And a simple solution.

what happens if no random/seed is used in a REBOL program?


That same thing that happens with almost all random generators, which 
is a pattern is used.  REBOL has a starting seed value (unknown with 
out extensive testing).  However, it will (and should) have the same 
value upon start up.

The problem (you are perceiving) is with the word "RANDOM" 

Perhaps it should be called PATTERN instead.  


However, if seeded, RANDOM in turn will use a formula to generate 
more in the series.  This is indeed true random, in as much as the 
seed's size sets the size of the universe.


So, if you want to always have a random set, you need to get fresh 
random data (hmmm, I seem to recall mentioning this in another thread).


Of note, the RANDOM we use in slot machines is NOT like REBOL's random 
function.


REBOL's RANDOM (like most language random functions) is really SEED+OFFSET 
in a series. (thus a pattern).


I'm not sure what Carl did to make it secure, but my best guess is 
he is sucking in what ever he can find to make it Random (this doing 
what I'm suggesting in the first place).


For example, reading the mouse port, temperature, current time (to 
the jiffy), etc.  This would make RANDOM what you expected it to 
be in the first place…but in theory this would be slower.  In your 
case,  this would be the way to go.

just pick words out of the evolution thread .. for random noise

LOL...

:-D

REBOL has a starting seed value (unknown with out extensive testing)

It seems to be 1. The first random call right after a startup will 
give the same result as random/seed 1 followed by the same random 
call. It's hard for me to see, what secure does, as seen in this 
example:
>> loop 10 [random/secure/seed 1 prin [random/secure 100 ""]]
47 47 47 47 47 47 47 47 47 47

I think, I should do, as I first suggested:
random/seed to binary! now/time/precise

before making my random password. If I put in a little wait, I can 
also make sure, I don't produce the same password two times in a 
row.

random/seed now/time/precise followed by an indeterminate number 
of
   random/secure to-decimal now/time/precise
or a few waits
will make it harder for anyone trying to guess your passwords.


But none of that guarantees you won't produce a random number you 
already have. If you need your passwords to be unique, you need to 
do one of several things:

-- check each one against all previously issued (as I've suggested)
-- generate a unique pool in advance (as Gregg suggests)


Both approaches introduce a potential security flaw: the table/pool 
of passwords is an attack point for a hacker.

Geomol, you need a single daemon to give you out random numbers, 
or, if you're on Linux, use /dev/random or something like that. to 
decimal! now/time/precise means that your numbers just cycle in 24 
hours, that is, i can easily predict what your password will be at 
a certain time of the day.

random/secure - it has been explained already, instead of using the 
libc rand() call, a crypto-safe random algo is used.

no /seed - rebol always starts with the same seed (not sure, maybe 
0), in order to allow testing

The starting seed seems to be 1.

Ah yes, there is a 24 hour cycle problem with my approach. I could 
construct a more unique decimal taking year, month and day into account. 
Hm, random/seed returns a value, if called with a decimal!? Called 
with an integer, it doesn't. A reason for this?
>> random/seed 100
>> random/seed 100.0
== 41.0

Maybe random ignore the /seed and just give me a decimal random number?

Yes, random/seed with a decimal doesn't use the seed:

>> loop 10 [random/seed 1 random/seed to decimal! now/time/precise 
prin [random 100 ""]]                                            
                           
52 52 52 52 52 52 52 52 52 52

So I need to construct an integer from the time.

This is misleading to me. I got the impression, that I could do
random/seed to decimal! now/time/precise
but that's no good! Should it be reported as a bug/flaw?

It seems, that
random/seed now
does exactly the same as
random/seed now/precise
(Only tested under OS X so far.)

Does anyone know, that now/time show at midnight? Is it 24:00 or 
0:00?

that -> what

try to switch you PC to 23:59 and do some loop which will print time 
:-)

Oh no, I go for 0:00. :-)

A suggestion for an algorithm to produce a random seed from the time:


s: to integer! 2 ** 32 / 86400 * (to decimal! now/time/precise) - 
(2 ** 31)
s: enbase/base debase/base to-hex s 16 2
reverse s
s: to integer! to issue! enbase/base debase/base s 2 16
random/seed s

It does this:
1) convert now/time/precise to an integer using all possible bits
2) make a string of 0 and 1 from it
3) reverse the string
4) convert it back to an integer
5) And finally use it as a seed


Doing it this way, I hope to have a good span of possible start values 
for the random generator. Did I miss anything?

Now I think of it, all this probably isn't necessary, because the 
actual number of possible outcome of my routine still is low compared 
to all the bits in an integer. I don't get 2 ** 32 possible passwords 
from this. If the routine is mainly used doing the day (maybe 12 
hours), I still just get half the possible outcome, even with all 
this, right?

So this should be about as good:

random/seed to integer! 2 ** 32 / 86400 * (to decimal! now/time/precise) 
- (2 ** 31)

This might be a good example to illustrate my point in the other 
thread about randomness and the difference between digital computers 
and analog human brains.


In my example, I'm about to produce a 8 character random password. 
Each character can be one of 60 possible chars. So I set up a random/seed 
with 2 ** 32 = 4'294'967'296 possible start values, so I can at best 
produce the same amount, 4'294'967'296, different passwords with 
my routine. I can't change this by putting new random/seed in after 
each character found, because of the determinism in how a computer 
work. I would need to get input from the outside to produce more 
different 8 char passwords.


As a human, I can pick between 60 possible chars, and I have to do 
it 8 times, so I can make 60 ** 8 = 167'961'600'000'000 different 
passwords. That's a lot more than the computer. When we go to abstract 
thoughts with no clear limits (like 60 and 8), we are far superior 
to the digital computer.


It would be much easier to make an artificial intelligence, if our 
computers were analog.

You could grab some starter randomness from
   http://random.org

Yes, something like that would be needed between each character to 
raise the number of possible passwords produced.

The pseudo-random generator used in REBOL (rand( ) C function) like 
in most other languages, is not limited to the size of the seed, 
it doesn't work that way. The seed just gives the starting point 
in a series of values produced by a math formula with a far greater 
range than the 32 or 64bits would give. So, if your code is correctly 
written, you'll get close to 60 ** 8 possible passwords (depends 
on the quality of value distribution in the internal math formula). 
The C rand( ) is notoriously poor, but far enough for most uses. 
IIRC python, for example, uses a different generator with a period 
or 2**19937-1.

John wrote "It seems to be 1."


And this is probably correct from a social point of view.  But I 
will stick with "unkown without extensive testing" because many integers 
can give the same sequence, and might even give the same sequence 
for a long time before they diverge.


This is the subtle point I'm trying to make about what is random 
vs pattern.


Things that "seem" are the reason hackers crack codes…this is where 
I used to start when I cracked other people's systems…

The seed just gives the starting point in a series of values produced 
by a math formula with a far greater range than the 32 or 64bits 
would give. So, if your code is correctly written, you'll get close 
to 60 ** 8 possible passwords


That's interesting. Do you know a good link, where I can read more 
about this?

google for pseudo number generator

pseudo random number generator

I guess that a good start woul be : http://en.wikipedia.org/wiki/Pseudorandom_number_generator

It puzzles me, how you can get more than 2 ** 32 possible outcome 
from 2 ** 32 different input, so I'll start reading... :-)

My test show, that random/secure give the exact same sequence of 
numbers every time, if started with the same seed. Check it with 
code like:

>> random/seed 1 loop 1000000 [random/secure 10000000] random/secure 
10000000
== 1253129

>> x: 1 loop 10 [random/seed 1 loop 1000000 [random/secure 10000000] 
if 1253129 <> random/secure 10000000 [print x] x: x + 1]


So I conclude, that I can only make 2 ** 32 different passwords with 
this, not 60 ** 8.

Do you need the passwords to be unique?

that random/secure give the exact same sequence of numbers every 
time, if started with the same seed

 That's an intended feature ! You should set the seed only *once* 
 with a random (or pseudo-random) value like now/time.