There are many algorithms to predict "break" the sequence.
Here is the most used algorithm to do so https://en.wikipedia.org/wiki/Berlekamp–Massey_algorithm .
Every pseudo-random number generator can be broken, the right question is how many numbers in a sequence you need to do so.
As a role of thumb if you have more topologies that can produce a complete sequence, it gets harder to predict the circuit topology, therefore, the sequence is more secure.
I know that LFSR are perfectly fine, but I do not understand why it is unlikely that the circuit I am proposing is less secure.
Do you have some evidence? That it is not ( the other ones have always been used since the 1950 ).
If you want to test or break the algorithm you are welcome and encourage to do so.
Here I can give you a list of nlprg, and the code is given at this link: https://gitlab.com/francescodellanna/nlprg/-/tree/master/examples
For cryptographic applications, statistical quality is necessary but not sufficient. A random number generator can have excellent statistical properties and yet be cryptographically weak.
For example, while the popular Mersenne Twister is suitable for statistical applications, it is not appropriate for use in cryptography because its future output can be predicted from past output by solving a system of linear recurrence equations.
The NIST Statistical Test Suite (STS) is recommended for testing CSPRNGs (cryptographically secure pseudorandom number generators) though it in no way guarantees an RNG is secure. The Mersenne Twister, for example, passes STS without any issues. STS is not a very demanding test for statistical quality, much less cryptographic quality, but it is a test any CSPRNG should pass.
Every CSPRNG should withstand "state compromise extensions". In the event that part or all of its state has been revealed (or guessed correctly), it should be impossible to reconstruct the stream of random numbers prior to the revelation. Additionally, if there is an entropy input while running, it should be infeasible to use knowledge of the input's state to predict future conditions of the CSPRNG state. Example: If the CSPRNG under consideration produces output by computing bits of π in sequence, starting from some unknown point in the binary expansion, it may well satisfy the next-bit test and thus be statistically random, as π appears to be a random sequence. (This would be guaranteed if π is a normal number, for example.) However, this algorithm is not cryptographically secure; an attacker who determines which bit of pi (i.e. the state of the algorithm) is currently in use will be able to calculate all preceding bits as well.
https://www.uobabylon.edu.iq/eprints/paper_1_17913_649.pdfIn practice, the output from many common PRNGs exhibit artifacts which cause them to fail statistical pattern detection tests. These include: • Shorter than expected periods for some seed states (such seed states may be called 'weak' in this context); • Lack of uniformity of distribution for large amounts of generated numbers; • Correlation of successive values; • Poor dimensional distribution of the output sequence; • The distances between where certain values occur are distributed differently from those in a random sequence distribution.
Defects exhibited by flawed PRNGs range from unnoticeable (and unknown) to very obvious. An example was the RANDU random number algorithm used for decades on mainframe computers. It was seriously flawed,[clarification needed] but its inadequacy went undetected for a very long time. In many fields, much research work of that period which relied on random selection or on Monte Carlo style simulations, or in other ways, is less reliable than it might have been as a result.
i would ask a crypto analyst first what the ramifications of that could be... it could as easily weaken the key as strengthen it.It produces a complete sequence.
a lot of crypto can be more easily broken by "reading" the EMI radiation from a computer's power supply, than by predicting the sequence or finding holes in the crypto method.This slightly more secure approach might be worth the power budget.
Yes. That was the fundamental flaw in the modified Enigma. A ciphertext letter could never be the same as its plaintext letter. The Polish mathematicians who were responsible for the initial cryptanalysis work on Enigma had already used that bit of knowledge towards cracking it. Ironically, this flaw came about when the Germans added a reflection rotor to the Enigma with the intention of making it more secure."there aren't any "D"s in the ciphertext." as it turned out, it was part of an effort to keep up the same volume of traffic to defeat traffic analysis, and the operator had just typed "DDDDDDDDDDDD..."
no matter where in the sequence you seed, the sequence remains the same, all you are doing by seeding a number is changing your start location in the sequence. for instance if you seed A2F7, and the next numbers are D17B, E8BD,F45E, and 7A2F, this is in a particular part of the sequence, so even if you started at 0000, once you get to the location in the sequence where A2F7 is, the next numbers will always be D17B, E8Bd, F45E, and 7A2F... you might as well store the whole sequence in an eprom and step through it incrementally. plus you want to add a 17th bit that is only used once, which is a waste of that bit. it would be better if you used that bit to double the length of the keyspace rather than satisfying some desire for "neatness". there may be a perfectly good reason sequences of 2^n aren't used, especially as this type or PRNG has been in use for a very long time, my guess that it would be because 2^n sequences have serious weaknesses cryptographically, otherwise 2^n-1 sequences wouldn't be so widely used as would 2^n sequences. it only takes tiny differences in the math to change a secure cryptosystem into one that leaks like a sieve...any number would work.
# include <stdint.h>
# include <stdio.h>
# define SEED 0xA013 // any seed can work
// bijective pseudo-random funcion
uint16_t nlprg16 ( uint16_t num )
{
return
(
(((~ ( num >> 15 ) ^ ( num >> 14 ) ^ ( num >> 5 ) ) & 0x0001 ) << 0 ) ^ // xnor stopper
((( ( num >> 13 ) ^ ( num >> 12 ) ^ ( num >> 0 ) ) & 0x0001 ) << 1 ) ^
((( ( num >> 11 ) ^ ( num >> 10 ) ^ ( num >> 1 ) ) & 0x0001 ) << 2 ) ^
((( ( num >> 9 ) ^ ( num >> 8 ) ^ ( num >> 2 ) ) & 0x0001 ) << 3 ) ^
((( ( num >> 7 ) ^ ( num >> 6 ) ^ ( num >> 3 ) ) & 0x0001 ) << 4 ) ^
(((~ ( num >> 5 ) ^ ( num >> 4 ) ) & 0x0001 ) << 5 ) ^ // closure connection
//(((~ ( num >> 7 ) ^ ( num >> 4 ) ) & 0x0001 ) << 5 ) ^ // alternative closure connection #1
//(((~ ( num >> 13 ) ^ ( num >> 4 ) ) & 0x0001 ) << 5 ) ^ // alternative closure connection #2
((( ( num == 0x001F ) | ( num == 0x000F ) ) & 0x0001 ) << 5 ) ^ // insert missing code 0x0031
(( num & 0xFFE0) << 1 ) // shift for all the other bits
) ;
}
// used to hide the 0x000F -> 0x001F -> 0x003F transition
uint16_t shuffle ( uint16_t num )
{
return
(
((( num >> 15 ) & 0x0001 ) << 5 ) ^
((( num >> 14 ) & 0x0001 ) << 8 ) ^
((( num >> 13 ) & 0x0001 ) << 15 ) ^
((( num >> 12 ) & 0x0001 ) << 10 ) ^
((( num >> 11 ) & 0x0001 ) << 9 ) ^
((( num >> 10 ) & 0x0001 ) << 12 ) ^
((( num >> 9 ) & 0x0001 ) << 13 ) ^
((( num >> 8 ) & 0x0001 ) << 6 ) ^
((( num >> 7 ) & 0x0001 ) << 11 ) ^
((( num >> 6 ) & 0x0001 ) << 0 ) ^
((( num >> 5 ) & 0x0001 ) << 2 ) ^
((( num >> 4 ) & 0x0001 ) << 14 ) ^
((( num >> 3 ) & 0x0001 ) << 1 ) ^
((( num >> 2 ) & 0x0001 ) << 4 ) ^
((( num >> 1 ) & 0x0001 ) << 3 ) ^
((( num >> 0 ) & 0x0001 ) << 7 )
);
}
// testbench for the non-linear pseudo-random generator
int main ()
{
uint16_t nlprg = SEED ;
int period = 0 ;
int verbose = 1 ;
if ( verbose ) printf ("type: d\ncount: 65536\nnumbit: 16\n");
do {
nlprg = nlprg16 ( nlprg ) ;
period ++ ;
//if ( verbose ) printf ("period %6d nlprg %6d\n", period, shuffle ( nlprg ) );
if ( verbose ) printf ("%6d\n", shuffle(nlprg) );
} while ( nlprg != SEED ) ;
return 0 ;
}
but you don't have that many bits in the keystream, you have 65536 long integers, which is only a stream of 1048576 bits, and then the pattern repeats...but you can not store 2^256 bits.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?