[OT] Getting a random number

[InuY4sha]

I'm trying to get a random seed for srand function, but it seems like
I can't use the time as seed, since the only function that allows that
is ctime, and when I use it inside my code I pass from 39Kb of binary
to 52Kb or so.. which exceeds my available memory... is there any
other way to get a random seed?
Or maybe is there a way to tell the compiler to just use the ctime
function and forget about all the rest of the library?
I'm programming on a C5471 Texas Instruments DSP.. and I don't see any
other way of getting a random event as seed... I mean... everything
not really random, but the time you start running the code...
Thanks and sorry for the OT
Cheers
RM

 

[Jens Thoms Toerring]

I'm trying to get a random seed for srand function, but it seems like
I can't use the time as seed, since the only function that allows that
is ctime,

ctime() looks to me rather useless for that purpose since it
just converts a time_t value to a string, did you perhaps
meant time()?

and when I use it inside my code I pass from 39Kb of binary
to 52Kb or so.. which exceeds my available memory... is there any
other way to get a random seed?
Or maybe is there a way to tell the compiler to just use the ctime
function and forget about all the rest of the library?

That's not possible to answer without knowing what compiler
and linker you are using. But then things wouldn't be a
question of C anymore but about the specific tools on your
machine and better discussed somewhere else.

I'm programming on a C5471 Texas Instruments DSP.. and I don't see any
other way of getting a random event as seed... I mean... everything
not really random, but the time you start running the code...

If your system has a clock (otherwise where would time() etc.
get its time from?) then there are probably also some system
specific ways (I guess you wouldn't mind to use them) to get
at it. But that's hardly a question for this group (perhaps
you will find some experts in comp.dsp and perhaps there's
even a random generator in the DSP for creating white noise?)
and none that I could answer.

Regards, Jens

 

[Richard Bos]

InuY4sha ha scritto:


(srand(getpid());

That's a fabulous way of getting a _non_-random seed when you call it
under several circumstances, many of which can happen on a DSP.

Richard

 

[vippstar]

InuY4sha ha scritto:


(srand(getpid());

Linux' default limit of pids is SHRT_MAX, so that's a bad idea.
It's not random at all.

 

[viza]

I'm trying to get a random seed for srand function, but it seems like
I can't use the time as seed, since the only function that allows that
is ctime, and when I use it inside my code I pass from 39Kb of binary
to 52Kb or so.. which exceeds my available memory... is there any
other way to get a random seed?
Or maybe is there a way to tell the compiler to just use the ctime
function and forget about all the rest of the library?
I'm programming on a C5471 Texas Instruments DSP.. and I don't see any
other way of getting a random event as seed... I mean... everything
not really random, but the time you start running the code...

http://xkcd.com/221/

There is no such thing as a software random number generator, so
hardware is the only true answer to your question. If your DSP has a
spare ADC you can create a chaotic resistor-capacitor network very
simply and use that.

If you don't have access to much hardware, then you can use something
like the process-id (as already suggested) but note that that will
only be random if it is directly influenced by hardware - that is, a
user application on a multi-user system is influenced by the hardware
(user-interfaces) that start processes. If your system process-ids
are not influenced by the user - eg: you always have the same small
set of services running - then they are no good.

So the answer is - think hardware, and if that fails think about
indirect hardware.

HTH
viza

 

[Keith Thompson]

I'm trying to get a random seed for srand function, but it seems like
I can't use the time as seed, since the only function that allows that
is ctime, and when I use it inside my code I pass from 39Kb of binary
to 52Kb or so.. which exceeds my available memory... is there any
other way to get a random seed?
Or maybe is there a way to tell the compiler to just use the ctime
function and forget about all the rest of the library?
I'm programming on a C5471 Texas Instruments DSP.. and I don't see any
other way of getting a random event as seed... I mean... everything
not really random, but the time you start running the code...

A common way to seed the random number generator is

srand(time(NULL));

Since using ctime makes no sense, I'm guessing that's what you meant.

Note that srand(time(NULL)) has several problems. One is that the
result of the time() function is of type time_t. The standard's only
guarantee about time_t is that it's an arithmetic type capable of
representing times. It could conceivably be a floating-point value
between 0.0 and 1.0; in that case, the above call would be equivalent
to srand(0). On real-world systems, this isn't likely to be a
problem, particularly if you're not concerned with 100% perfect
portability.

Another problem is predictability. If an observer knows, or can
guess, when the program started, he can anticipate the stream of
random numbers it's going to use. For cryptographic applications,
this is a fatal flaw. For other applications, it might not matter.

Finally, the algorithm used by the rand() provided with a C
implementation is often not very good.

If the system time and the rand() function are good enough for your
purposes, but you can't use the time() function, you'll have to find
some system-specific way to get the current time. I have no idea what
that might be, but the time() implementation must use some underlying
mechanism.

Is there any possibility of obtaining some random data (to be used as
a seed) from an external source? Or can you maintain the state of
your random number generator on the system between runs, so you don't
have to re-initialize it each time (though that could cause
predictability problems).

Beyond that, I don't think there's much help we can offer here. You
might try comp.arch.embedded or comp.dsp.

 

[Hallvard B Furuseth]

That's a fabulous way of getting a _non_-random seed when you call it
under several circumstances, many of which can happen on a DSP.

Can still grab it in addition to time() though, and mix both to get a
seed. Other things one could try to mix in:
- clock() with time used by the eprocess.
- an uninitialized unsigned int variable on the stack - might
get a garbage value from elsewhere in the program.
- (unsigned) <the address of a variable on the stack>
- (unsigned) <some malloced pointer>
Though first look around for system-dependent functions. Such as:
- Are you sure there is no equivalent to a /dev/random device?
- Or some other input device you can grab some garbage data from?
- a time function with better resultion. gettimeofday()/ftime()?
- old user input or events which might be lying around in a buffer
somewhere. In particular if these have times attached.
Anyway, all that belongs on a forum for your OS/C implementation.

 

[Hallvard B Furuseth]

Another problem is predictability. If an observer knows, or can
guess, when the program started, he can anticipate the stream of
random numbers it's going to use. For cryptographic applications,
this is a fatal flaw. For other applications, it might not matter.

Yes. If predictability is a problem, some of my user input and
"hopefully random" suggestions may be worse than useless - they may
enable a user to _force_ a particular seed.

 

[inuy4sha]

A common way to seed the random number generator is

srand(time(NULL));

Since using ctime makes no sense, I'm guessing that's what you meant.

Well I read the includes/time.h header file in the compiler folder, and I
only saw the ctime function It was very stupid of me to think straight
that this would be the required function .. but I hadn't use the time.h
structures and function before, so I fall for that...

Note that srand(time(NULL)) has several problems. One is that the
result of the time() function is of type time_t. The standard's only
guarantee about time_t is that it's an arithmetic type capable of
representing times. It could conceivably be a floating-point value
between 0.0 and 1.0; in that case, the above call would be equivalent to
srand(0).

If I remind correctly, the time_t was a standard unsigned integer... but
I'll check tomorrow and eventually let you know.

Another problem is predictability. If an observer knows, or can guess,
when the program started, he can anticipate the stream of random numbers
it's going to use. For cryptographic applications, this is a fatal
flaw. For other applications, it might not matter.

I need this random number to generate random backoff idle periods in a
wireless network

Is there any possibility of obtaining some random data (to be used as a
seed) from an external source? Or can you maintain the state of your
random number generator on the system between runs, so you don't have to
re-initialize it each time (though that could cause predictability
problems).

I could get the seed from an ARM which the DSP communicates with.. the
ARM is more powerful and doesn't have memory limitations. But it's a
dirty hack.

Beyond that, I don't think there's much help we can offer here. You
might try comp.arch.embedded or comp.dsp.

I'll try that for sure, and this was far more than what I expected

 

[Tomás Ó hÉilidhe]

There is no such thing as a software random number generator, so
hardware is the only true answer to your question.  If your DSP has a
spare ADC you can create a chaotic resistor-capacitor network very
simply and use that.

That crossed my mind too, i.e. using the A-to-D to get some sort of
random voltage from somewhere, but I wonder how you'd get a random
voltage? What is a "chaotic resistor-capacitor network"?

 

[inuy4sha]

ctime() looks to me rather useless for that purpose since it just
converts a time_t value to a string, did you perhaps meant time()?

I apologize, I saw that in time.h and in the man page of gettimeofday (if
I recall right) so I thought it was the function I was looking for... and
I was wrong I guess

 

[Jens Thoms Toerring]

If I remind correctly, the time_t was a standard unsigned integer... but
I'll check tomorrow and eventually let you know.

Not 100% correct, the C standard doesn't require more than
that it is an "arithmetic types capable of representing
times", so in principle it could also be e.g. a double.
And if the time cannot be represented the return value
of time() is (time_t)-1 (whatever that exactly is;-). But
since what you want to do seems to be rather system spe-
cific and not meant to be portable, I wouldn't see any
harm in checking what time_t is on your system and use
it if it's an int or unsigned int.

Regadrs, Jens

 

[viza]

Hi

That crossed my mind too, i.e. using the A-to-D to get some sort of
random voltage from somewhere, but I wonder how you'd get a random
voltage? What is a "chaotic resistor-capacitor network"?

one example:
http://en.wikipedia.org/wiki/Chua's_circuit

It's a bit more complicated than I remembered, you need at least a
couple of diodes and an op-amp as well as Rs and Cs (in this one, at
least - others exist if the dual voltage requirement of an op-amp is a
nuisance to you).

viza

 

[viza]

Hi




one example:http://en.wikipedia.org/wiki/Chua's_circuit

It's a bit more complicated than I remembered, you need at least a
couple of diodes and an op-amp as well as Rs and Cs (in this one, at
least - others exist if the dual voltage requirement of an op-amp is a
nuisance to you).

PS:
An alternative is to use some kind of sensor (eg: microphone) to input
random data. If you use something like that you will have to test by
experiment how random it really is, eg: does it consistently give zero
at night when it is quiet, does it always saturate in the rush hour
when it is noisy. Can attackers reproducibly influence the value, and
does that matter to your application.

 

[Keith Thompson]

Well I read the includes/time.h header file in the compiler folder, and I
only saw the ctime function It was very stupid of me to think straight
that this would be the required function .. but I hadn't use the time.h
structures and function before, so I fall for that...

[...]

I wrote the above quoted text, starting with "A common way ...".

Your newsreader should have generated an attribution line, something
like "(e-mail address removed) (Keith Thompson) writes:".

Please leave that line in place when you quote somebody in a followup.
It makes the discussion easier to follow, and it's just polite to give
credit when you quote somebody else's words.

 

[Peter Nilsson]

InuY4sha ha scritto:

[Other than time()...] is there any
other way to get a random seed?

(srand(getpid());

Linux' default limit of pids is SHRT_MAX, so
that's a bad idea. It's not random at all.

There's no requirement for unsigned int to have
a range larger than USHRT_MAX. You're effectively
saying that _any_ attempt to portably call srand
is a bad idea.

 

[Richard Tobin]

Linux' default limit of pids is SHRT_MAX, so
that's a bad idea. It's not random at all.

[/QUOTE]

There's no requirement for unsigned int to have
a range larger than USHRT_MAX.

Given that the system has getpid(), this is not likely to be the case.

-- Richard

 

[vippstar]

There's no requirement for unsigned int to have
a range larger than USHRT_MAX.

Given that the system has getpid(), this is not likely to be the case.[/QUOTE]
As Mr Tobin noted, this is not the case with systems that have POSIX
getpid(), because POSIX requires UINT_MAX to at least be 2**32-1.
(However, standard C requires UINT_MAX to be at least 2**16-1, 65535)
There was a security issue with debian a while ago in the OpenSSL
package. The initial seed was only the getpid() value.
<http://www.debian.org/security/2008/dsa-1571> for more information.

 

[Ben Bacarisse]

I need this random number to generate random backoff idle periods in a
wireless network

If you have access to the network hardware, the MAC address (or
similar) might be all you need. In addition, wireless hardware often
records things like signal and noise levels that are likely to vary
from node to node.

 

[Joachim Schmitz]

If you have access to the network hardware, the MAC address (or
similar) might be all you need.

But that then would create very predictable 'random' numbers.

In addition, wireless hardware often
records things like signal and noise levels that are likely to vary
from node to node.

But not so much for a certain node. Probably more than the MAC though...

Bye, Jojo