Answer the question
In order to leave comments, you need to log in
How to correctly generate pseudo-random numbers?
Good day. One formula can be extracted
from the article on Habré
:
But when using this formula, I don’t get exactly what I need.
Therefore, how to correctly generate pseudo-random numbers by any algorithm? (Like, for example, in Python with random.randint(arg1, arg2)
or like in Java when using new Random().nextInt(100)
PS : The labels indicate Python and Java , but in fact any language, preferably C-like, will do.
Answer the question
In order to leave comments, you need to log in
Judging by your comment on Ivan Sokolov 's answer, you do not understand the essence of your own question.
Any, I repeat, absolutely any , pseudo-random number will be in some sequence , and the sequence itself will be built according to some formula.
I very deeply doubt that anyone will ever be able to get a completely random number, because. any accident is an unknown regularity!
A separate question is how predictable the appearance of numbers in your sequence is. This is where all your searches should be.
Take, for example, the rand() function from any programming language. It will generate a pseudo-random number based on timestamps in unixtime. How predictable is she? Hmm, I think at least 100%. Well, it turns out that knowing the approximate run time of the rand () function, say, with an accuracy of 1 minute, we can get exactly the same pseudo-random number. Excellent, i.e. This is where you need to dig.
Let's assume that we pulled out a list of companies from the Unified State Register of Legal Entities in Moscow and took their ORGN. Further, our function generates unixtime and we subtract this same OGRN from it, and the last two digits in unixtime and OGRN must match (for example, the condition for choosing OGRN can be any). What have we achieved? Knowing the running time of the rand() function, we cannot generate a second exactly the same pseudo-random number. You can now object to me that let's take the same OGRN and repeat the procedure. At this point, I want to ask you a question: who are we building protection against? The attacker is the creator of the system and knows 100% about it? I think any defense in this case is simply meaningless.
You must introduce some unexpected behavior into your generation formula, which will be different from what is in the standard implementation. It will be some kind of OGRN, birthdays of your colleagues, user IDs in VK, etc. This feature is not known to an external attacker.
Will your series of pseudo-random numbers be more or less random? Hmm... A big question... At this point, we recall again what an accident is.
Will this increase the security of the system? I think in part it can, because the attacker does not know the generation algorithm, although this is bad to a certain extent.
Summarizing all of the above - to make your series of pseudo-random numbers more random, you need to add a number from another series of something pseudo-random to the formula for generating it. I also strongly recommend checking the resulting pseudo-random number for simplicity if you are going to use it as a value in generating a secret key for GOST or RSA
Almost all pseudo-random number generators generate sequences where, knowing the initial number (seed), you can repeat the entire sequence. To generate truly random numbers, hardware devices or the accumulation of entropy events (delays between keystrokes, mouse movements) are used.
The code that uses Java is given in the same article, as is the code that restores the seed from two consecutive nextInt results.
Hmm ....
Either the skis do not go, or I ......
We read:
These are two opposite concepts.
Pseudo-random - obey the law (generation formula).
Random - respectively, no.
Therefore, if, nevertheless, random ones are needed and so that no one guesses, then we use the dynamic parameters of the external environment (for a particular case, parameters from the OS): temperature from sensors, amount of free / used disk space, amount of used / free memory, number and process IDs, etc.
Parameter selection criterion: rapidly and unpredictably changing value in time and independent of the algorithm in the generator code, inaccessible from outside.
We hash the parameters with timestamp by any algorithm and take some part from the received hash.
IMPORTANT!Parameters for hashing should not be publicly available: no external requests with TIN, OGRN and GISMETEO! )
The simplest option: We took a picture and made any transformations with it, then saved it into a data stream, took any or several bits. We generate a picture based on external factors and never put it in the source code of the algorithm.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question