/tech/ - Technology

From my understanding, for something to be truly random, you have to base the outcome on data from something else (that is truly random) that is outside the programed system. Cloudfare famously uses lava lamps.

>>12595
You would have to verify that the algorithm used isn't somehow biased, and also that your source is something unpredictable, like thermal noise, or some other random oscillator. If you can verify that the computer making decisions is using those things then I guess you can trust the results.

>>12596
>>12597
You don't get it.

Assume that the seed is truly random (by using lava lamps or whatever other source of real entropy).

Now assume you have an infinite set of truly random seeds.

Now what prevents you from brute forcing PRNG algorithm using this infinite set of random seeds until you achieve a non-random outcome?

ie, assuming true randomness, what is the PROBABILITY of arriving at a specific vector by repeating the same PRNG algorithm?

>>12598
The fact that it's infinite, and your brute force would literally never finish.

>>12599
The probability here would just be 1 over the cardinality of the set of seeds, which if your set of seeds grows without bounds your probability approaches 0.

>>12600
>The fact that it's infinite, and your brute force would literally never finish.
Wrong. It would finish when you arrive at a desired output vector.

Are all PRNG algos asymmetrical?

ie, is there a way to arrive at the seed from the particular output vector?

>>12602
If S is the set of all your seeds, you choose an element s1 from S and apply your function to it: PRNG(s1) = x.

If x is your desired output, you quit, otherwise you check the next s2. Buf if there are an INFINITE many s values in S, then the chances of you finding the right x are ZERO.

>>12604
>Buf if there are an INFINITE many s values in S, then the chances of you finding the right x are ZERO.
Why? How is x dependent on the size of the set S?

Also, wouldn't it depend on the function too?

>>12604
fn PRNG(seed: []char) int: return seed[0] ^ 1;
this function takes an arbitrary sized string as seed and returns a random number (0 or 1). it would be trivial to bruteforce a desired outcome
>inb4 but the number of seeds isn't really infinite in this case
fuck off

>>12595
1. generate the seeds before the list of names. for example, they could publish a list of seeds for the next ten years, before the list of names for every year are even compiled
2. pick from an otherwise limited number of seeds: the unix timestamp at the moment the procedure was run, for example. this way the seed itself is kind of predictable but it is harder to bruteforce a particular outcome
3. generate the seed from the list of names itself through another open-source and publicly available procedure
4. all of the above at the same time

in all these alternatives the public could reproduce the procedures and the only way to skew the results would be to, not only bruteforce the desired seed, but also skew and/or anticipate the lists of names

>>12606
well, the list of names could be compiled in the strict alphabetical order to prevent manipulation on this end

but the seed looks like the chicken and egg problem - ideally you would want a random seed, but to get a random seed itself you ideally would want another random seed..

I guess we need to assume that the seed is a-priory DETERMINED.

So the source of randomness should come from the list of names.

>>12607
>but the seed looks like the chicken and egg problem - ideally you would want a random seed, but to get a random seed itself you ideally would want another random seed..
ie the genuine source of entropy could be only in some physical process

but who controls access to this process - controls derived randomness

>>12607
>the seed looks like the chicken and egg problem
not really, in (1) and (2) the seed is predictable
with (3) you start with a random seed (the list of names). remember, any piece of data can be a seed, and in a weird way, the list of names is a physical source of entropy

still, the smaller the list of names, the easier it is to manipulate the result. and the bigger the list is, the easier it becomes to add fake names without people noticing. take this python example

import random
def seed(names):
str = ", ".join(names)
random.seed(str)
def choice(names):
seed(names)
return random.choice(names)
def fake(names, fake_name):
fake_list = names + [fake_name]
return choice(fake_list)
#names is a list of strings, fake_name is a string

start with a small list of names (5 or 10) and set one as your desired outcome; now call fake() with that list and a fake name. it won't take you many attempts to roll your desired outcome. you only need one fake name to manipulate the results in your favor

>>12613
a combination of (1) and (3) may work better:
instead of using the current list of names as the seed, you could use a previous list