Random Generator Seed Question C++

[DaveLembke]

So obviously if you just use a random generator each time to run the random generator you would end up with the same pattern of numbers spit out by the algorithm.

Seeding is usually gone to use the time as the random so that the output is more random even though still follows algorithm.

Looking online I was wondering if you could set a manual seed value by user a sort of seed injection as a starting place for the random generator to run from?

Google search has come up dry so I figured I'd ask here. Using C++ and never injected a seed for random generator before to set a manual offset like this and would like to do this if possible as a key for a specific value chain to be output based on the key value.

[DaveLembke]

Ok I think I found the solution to what i was looking for. Its tucked in the comments at the bottom of this linked page.

http://www.cplusplus.com/forum/beginner/29699/

Bazzy (6281)
You can replace time(NULL) with any interger eg: srand(1234);
( if you seed the PRNG with a fixed value, you'll get every time the same sequence )
NULL is a time_t pointer http://www.cplusplus.com/reference/clibrary/ctime/time/ http://www.cplusplus.com/reference/clibrary/ctime/time_t/

[Geek-9pm]

So obviously if you just use a random generator each time to run the random generator you would end up with the same pattern of numbers spit out by the algorithm.

Really?  Are you sure?
If you do not want the same sequence, don't ask for it. 
Possible relevance:
https://en.wikipedia.org/wiki/RdRand

[DaveLembke]

Cool thanks for sharing that Geek. I wasnt aware of that change to CPUs for a better random generator with better seed. Surprised they havent come up with a CPU with a very small amount of americium and a micro or nano geiger counter to use the radio active decay rate as the seed or algorithm interrupt to jump to another sequence like a phase shift in the algorithmic calculation process.

If ok for smoke detectors I suppose if someone implemented it it would be ok for a CPU.

https://en.wikipedia.org/wiki/Americium

[Geek-9pm]

The Wikipedia article is very critical for Intel and others for putting it inside of the CPU. So you have a sealed generator which can not be removed and verified in a laboratory environment. Anything inside the CPU could by hacked by microcode and ruin the whole idea of using a random generator for security.

There are some other ways, but if we start talking about it, the connection will be reset. Happens every time. 

PS the Linux community wants an open source random generator.
And the link you gave goes on to say:

Americium often enters landfills from discarded smoke detectors. The rules associated with the disposal of smoke detectors are relaxed in most jurisdictions. In the U.S., the "Radioactive Boy Scout" David Hahn was able to concentrate americium from smoke detectors after managing to buy a hundred of them at remainder prices and also stealing a few.[109][110][111][112] There have been a few cases of exposure to americium, the worst case being that of Harold McCluskey, who at the age of 64 was exposed to 500 times the occupational standard for americium-241 as a result of an explosion in his lab. McCluskey died at the age of 75, not as a result of exposure, but of a heart disease which he had before the accident.[113][114]

[DaveLembke]

Anything inside the CPU could by hacked by microcode and ruin the whole idea of using a random generator for security.

True... There will never be a system that is totally immune I feel. Technology will just have to keep evolving to try to stay one step ahead of exploits at the risk of the newer technology opening up more vulnerabilities.

[Geek-9pm]

Well, IMHO, this is what they could do.
Create a small, cheap device tat does just a few things.  It would gicve out true random numbers and also have some math functions needed for cryptography. It would be a small plug in module that would plug into the motherboard. It must be open source.  It would be made and sold by many. It could be tested dependability of the motherboard. It would have a log of the last long sequence given. Thus it could be proven to be independent of the CPU microcode.
It would almost be an external device, except we want in inside the case for sec purity reasons.

An enterprise might have a procedure for removing and ewplacement of the devices from time-to time.

Thermal noise diodes have demonstrated the ability to generate long sequences without repetition, unlike software algorithms.

Really , a noisy diode is  almost  cheapest thing you can buy.
https://en.wikipedia.org/wiki/Noise_generator
A DIY project:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/3469

A similar version of this article appeared in the September-October 2004 issue of Electronica magazine.

So, you could make your own! 

[camerongray]

One thing that can be done is to use some sort of software defined radio such as an RTL-SDR or HackRF to sample radio noise and use that to generate random numbers, this is what random.org uses.  An RTL-SDR dongle can be picked up for as little as $10 and software such as this can be used to extract random numbers from the radio noise: https://github.com/pwarren/rtl-entropy

I've posted previously about SDRs here: http://www.computerhope.com/forum/index.php/topic,152669.msg937163.html#msg937163

[Geek-9pm]

Camerongray, Thanks for the links. So one could use random.org to get a long list of true random numbers. Great!

[DaveLembke]

Cool stuff. Thanks for sharing that info.

First time hearing about white noise for random number generation. But I suppose if you sample white noise and it has no predictable harmonics at the sample rate and use the amplitude of the signal at the sample interval you could assign a value to the measured interval and use that.

Never heard of Random.org going there now to check that out. With the radio noise though I am curious as to if it could be hacked by transmitting a radio wave with say a 60Hz tone, saturating the radio so that it takes a precise harmonic 60 hz tone making for greater predictability of the random output by defeating the randomness of noise and feeding it a perfect tone. 

[Geek-9pm]

Well, putting a strong signal next to their location might be a violation of FCC rules.
In any case, you have to trust somebody to provide a reliable source of reference values for a secure security system for the internet and the local network.  As stated earlier, the built-in CPU generator could be hacked by malware and it could be very hard to detect once it did its job.

So you would want to test your security codes from time to time to see if they are truly random or not. As was also said, somebody with an evil mind will find some way  to break it.

One would think the NSA would prohibit the use of true random generators.
Of interest
http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/

“We cannot trust” Intel and Via’s chip-based crypto, FreeBSD developers say
Following NSA leaks from Snowden, engineers lose faith in hardware randomness.
by Dan Goodin - Dec 10, 2013

[BC_Programmer]

The way to avoid possible compromise of the CPU Crypto features is to not use it. As the article Geek-9pm notes, Most Open Source Operating Systems, such as BSD, specifically avoid using the RDRAND instruction because it cannot be audited.

Thinking about it, I could have sworn this topic came up previously and I mentioned you could seed a fixed value to get the same sequence, but I can't seem to find it- that's Deja Vu for you I suppose.

[Geek-9pm]

Thinking about it, I could have sworn this topic came up previously and I mentioned you could seed a fixed value to get the same sequence, but I can't seem to find it- that's Deja Vu for you I suppose.

With a pseudo-random thing, a seed takes you back to a specific point in the loop. This is documented either in the  .NET stuff or somewhere like that. Look in the Visual Basic 6 manual.
Example.
http://www.developerfusion.com/code/259/generating-random-numbers/

[BC_Programmer]

.NET uses the modified version of the Subtractive Random Number Generator described in Donald Knuth's "Art of Computer Programming- Volume II: Seminumerical Algorithms" It's tricky to remove directly from the context- it describes the original algorithm as having a periodicity of around 74 quadrillion numbers (which, I presume based on context refers to the length of the sequence- with seeds changing, effectively, the starting location). However, after presenting the modified algorithm, Knuth continues to describe it:

The somewhat curious maneuverings of ran_start are described in exercise 9, which proves that the sequences of numbers generated from different starting seeds are independent of one another.

So the sequences from that algorithm are unique.

However, pertaining to the topic- C uses a linear congruential algorithm, which does have a period.

What isn't entirely clear is whether the period indicates when a particular seed's sequence repeats, or whether it indicates that there is one sequence and the seed selects a starting position within it.

[Geek-9pm]

Very interesting. Security and encryption are part of the history of Cybernetics. In World War II there was a need to mike codes that could not be easily cracked and there was a need to crack the codes of the adversaries. That was before potable computers were available.

Now here we are with computers that could do very high security encryption, yet everyday we hear about some hacker getting into a list of credit card numbers. What's wrong with this picture?

Here is a breaking story....
Google Chrome’s JavaScript engine finally returns actual random numbers

Over the years, multiple studies have found that Google Chrome’s V8 JavaScript engine was returning not-so-random numbers when you called the Math.random() function.
Today that’s been fixed, with the release of Chrome 49, which will be available soon. Math.random() is the most frequently used way to generate randomness in Javascript, which is an important component of many web applications.

Has pictures before and after. 

From another link:

    The number of random values it can generate is limited to 232 as opposed to the 252 numbers between 0 and 1 that double precision floating point can represent.
    The more significant upper half of the result is almost entirely dependent on the value of state0. The period length would be at most 232, but instead of few large permutation cycles, there are many short ones. With a badly chosen initial state, the cycle length could be less than 40 million.
    It fails many statistical tests in the TestU01 suite.

http://v8project.blogspot.de/2015/12/theres-mathrandom-and-then-theres.html