Talk:Wizardry and Steamworks/Randomness, Entropy and Statistics

"There is no obvious reason for a region to have a cyclic FPS"

I can think of one: a periodic services used to backup the simulator state. It should cause a dip. I worry about the quality and quantity of bits available from llGetRegionFPS, choosing the wrong max could skew results dramatically. -- Strife ^{(talk|contribs)} 12:02, 13 January 2012 (PST)

Not convinced it is that obvious: but would make a nice project for some volunteers to test this out!

That is true however, there are many other concurrent processes running in parallel with a backup process which may alter the FPS in un-predictable ways. Similarly, just the usage of the simulator by the avatars would induce fluctuations. Additionally, as I take it GPU operations are split off from CPU driven operations (after all, that would be the point for an auxiliary processor).

I am unsure whether:

1. there is a back-up process running or its periodicity
2. whether it would provoke a massive and cyclic (truly periodic) fluctuation on the lower mantissa of the reported FPS number.
3. whether the cumulative: avatars and tasks on the simulator, backup process and additional processes that may run on simulator servers
4. the database for a simulator is not centralised and backed-up or if the simulator itself performs the backing up.

would lead to some true cyclic induced error: careful here, we're talking about an well-defined T, not just some random fluctuations.

Either way, we find it pretty clear that even avatars, provided they have rez / scripting permissions over the land may inject some true T periodicity in the FPSrand method: in the later, coming up (, when we have more time) demonstration, we will use a lag-pulse generator to influence the entropy.

So far, llGetRegionTimeDilation and llGetRegionFPS are the "best we have" candidates for some source of true entropy given what Second Life exposes on the API. However, OpenSIM users, would giggle and jump up and down because they have that stats-function mentioned in the article that returns stuff such as: In/Out Packets, Network Lag and pretty much everything else from the View -> Show Statistics - which is pretty cool. :-) The mentioned OpenSIM API function could be used to harness additional entropy: sort of like selecting a little of each and decreasing the chances that an adversary (under some restrictions) could influence ALL the sources of entropy at will.

For Second Life though, some exhaustive search of the functionality that is exposed by Linden on the API relating to simulator statistics would be great. Perhaps there might be some other function out there that may offer a potential source of entropy... At least we know that stuff like llWind is out of the question...

EDIT: ah yeah, for got this: the TRNGs work correctly in ideal conditions, of course. The real-life TRNGs, some of them, gather data from wind. Of course, if you put a blow-dryer directly on the detector, it will not be worth much anymore... :-P Hence the need for several sources (like OpenSIM), or at least not some gimmick with a blow-dryer and a bad attitude. xD

Kira Komarov 12:42, 14 January 2012 (PST)

---

Events hosted in the region (or any of the other regions run on the same server) would also generate scheduled lag.

As for making small modifications, I was thinking about flipping an object's STATUS_PHYSICS on and off, it should have a very small impact (least significant bit sort of thing, which is the most significant bit with regards to modulo).

The big difference between this and the commercially available ones is ease of third party manipulation. Your hair dryer attack is valid but can't be done by someone in Asia. I would personally be more comfortable with using llWind (both are extracting data from simulations), my reasoning being that you can't manipulate llWind easily (you might have to terraform the ground to do so and that requires land mod rights, big spinning objects have no effect). llWind and llCloud both are black boxes that would worry me. -- Strife ^{(talk|contribs)} 20:38, 14 January 2012 (PST)

---

No, that won't work. llWind and llCloud are computed values - they are predetermined by a fluid dynamics simulation. You cannot make a TRNG based on computed values or you will get a PRNG instead. You have to have measured data. Stuff that generates lag is also ok as long as it does not induce a period - regardless if it increases or decreases from time to time.

Let me put it differently: You cannot inject PRNG values into a TRNG or you will get a PRNG. With llWind and llCloud, if you do it that way, you will get a PRNG, no better than llFrand (perhaps a little): you need something measured, not something computed. Stuff like FPS, in-out packets, hard-disk movements are measured - you may influence them, but they are not computed.

Also flipping the status on and off will practically make an oscillator out of your object - that is something you want to generically avoid. If you meant for an attack, a pulse-oscillator, flipping a single object's physical status will not have that much of an outcome for a region: it is just one object and usually there are countless other objects on a region that influence the FPS. You need something that has a drastic impact on FPS, to offset all the other objects on a region.

As you said, the blowdryer attack cannot be performed by somebody that does not have direct access to my detector. However, if you use osGetRegionStats and take a little bit from each one of these:

STATS_TIME_DILATION	0	STATS_IMAGE_MS	11
STATS_SIM_FPS	1	STATS_OTHER_MS	12
STATS_PHYSICS_FPS	2	STATS_IN_PACKETS_PER_SECOND	13
STATS_AGENT_UPDATES	3	STATS_OUT_PACKETS_PER_SECOND	14
STATS_ROOT_AGENTS	4	STATS_UNACKED_BYTES	15
STATS_CHILD_AGENTS	5	STATS_AGENT_MS	16
STATS_TOTAL_PRIMS	6	STATS_PENDING_DOWNLOADS	17
STATS_ACTIVE_PRIMS	7	STATS_PENDING_UPLOADS	18
STATS_FRAME_MS	8	STATS_ACTIVE_SCRIPTS	19
STATS_NET_MS	9	STATS_SCRIPT_LPS	20
STATS_PHYSICS_MS	10

Then an adversary would have to influence them ALL to mess up your entropy, and that practically reduces their chances to unplugging the computer - then again, with that sort of access, llFrand will not work either. They will have to influence:

network AND all other scripts on the region AND stuff like frame time AND pending uploads even AND time dilation AND number of ACTIVE primitives AND AGENT related measurements... etc...

So they will have to be able to control network, your rendering capabilities, how many agents are on your land, the activities that those agents perform, the number of objects at a given time on the region... We can already stop there, that is impossible, short off from turning the machine off.

The discussion is between deterministic systems and non-deterministic systems; if you want a short answer: a physics simulation like llWind or llCloud is deterministic, even if at any point in time it may be difficult to describe what state it is in. No matter how difficult it is, it will still be a PRNG. The number of avatars in a region is non-deterministic: you cannot vouch how many there will be at any point in time. It is not difficult, it is impossible.

EDIT: here's another example: for a high-traffic zone like an infohub, just counting the number of avatars (instead of using the FPS count) in the region is sufficient for a TRNG: it is non-deterministic. The number of pigeons in a city centre, at a certain point in time, during spring and summer, is also non-deterministic - although you may have to cut-off winter time periods if the birds migrate.

Kira Komarov 04:53, 15 January 2012 (PST)