im sure many of u have thought about it before

2 cpus with same manufacture pieces identical to each-other.
both asked to choose 2 random numbers between 1-100 (for the first time) using any same software (algorithm)
both will always choose the same 2 pair of numbers.
so if we rely on computers to generate "random" numbers, we could technically predict the future to a T.
there was an IFC movie about something like it, i think PI was its name (like the πumber)

but this is why C isn't truly random and never can be (spoiler):

http://www.dreamincode.net/forums/topic/24225-random-number-generation-102/

Cool sig that must've been hard to rip

i also made this one, nn rage: http://forums.d2jsp.org/img.php?x=337268



This post was edited by VPN on Sep 30 2013 01:17pm

That is assuming you ask them for the numbers at the same exact time, which is problematic on many levels.

You can get an extremely good pseudo random numbers from a computer by using the system clock. If you want truly random numbers, you need to add special hardware that can produce truly random numbers (this is generally an overkill, as the pseudo random numbers normal hardware can produce are good enough for most applications).

this is assuming the random algorithm has a variable of current* time, in most cases i bet u it is not.

This post was edited by VPN on Sep 30 2013 02:37pm

This is a discussion on entropy, not crypto class PRNG, which is an entirely different topic.

A comon practice for entropy on *NIX platforms is to pull a few bytes from the kernel's memory space. On Windows platforms, Microsoft provides its own closed source entropy generator, which is supposedly crypto ready. In the end, the overall resilience of an implementation depends on which entropy source is used with which PRNG. From a realistic attacker's standpoint, exploiting implementation weaknesses and thus possibly injecting entropy is a much better attack angle than trying to predict any part of the PRNG state.

i was assuming C++ / Coding a Linear Congruential - and both systems in my vacuum would pull the same closed source generated bits.

This post was edited by VPN on Sep 30 2013 09:00pm

If every steps afftecting entropy were taken in the exact order, by identical machines, assuming no external sources of entropy are involved both machines would yield the same result. That's the basic principle behind stream cyphers. The password is essentially the source of entropy which is used to create a stream of pseudo random bytes against which the secret is XOR'ed.

Now assuming your source of entropy is simply the system clock, let's say Windows' GetTickCount(), then you need both machines have similar CPUs (and most likely northbridge as well) and also similar install since you need the system to start its clock within the same OS time quantum, and perform the exact same operations on both computers so as to achieve identical behavior from both thread scheduler (that means same mouse moving and keystrokes and all). That's the amount of conditions you'd have to clear to achieve identical entropy, and thus predict PRNG results. And I think time based entropy source are the weakest out there.

Now try to achieve this with kernel pulled entropy and you're in for a treat. Everything has to be identical, every single action has to be performed within the same time quantum. Theoretically possible though. If you add an external source of entropy, like pulling entropy from 3rd party in an atomic and incremental fashion, such that the same entropy cannot be pulled twice, nor can it be pulled at the same time, then all bets are off. You'd have to find a point in time where entropies converge, or create the situation by exploiting implementation holes, and that doesn't even guarantee they won't diverge again, since the proper practice is to pull entropy for every independent crypto routine, i.e. you should reset your state before building a new private key or random constant for an EC message signature

ssh (and other protocols) public/private keys r reversible im sure... your understanding of this thought is further researched than mine. but given basic principles, the movie pi has a chance:

http://www.youtube.com/watch?v=jo18VIoR2xU

This post was edited by VPN on Sep 30 2013 10:52pm

The very point of ECDSA as a crypto tool is that elliptic curve point multiplication acts as a trap door function, i.e. there is no such thing as a discrete solution to an elliptic curve division. Brute forcing the multiplication is another story, but that one is much harder than brute forcing hash functions or block/stream cyphers, as ECDSA requires prolly over x1000 more cpu time than stuff like AES or SHA2

This post was edited by flyinggoat on Sep 30 2013 11:06pm