Hi i am trying to build a key stream generator for my homemade stream cipher.The key stream output has a close to maximum entropy value and a large periodicity. What does it take for this generator to be secure from various attacks?
What does a high entropy mean security wise? I am confused with this at the moment.
Thank you for spending your time.
Entropy is a property of a physical process or a state of knowledge, not a property of a deterministic function such as a stream cipher, or of a value such as a specific password.
A stream cipher—a deterministic mathematical function—is considered secure if an adversary who does not know the $k$-bit key chosen uniformly at random and can only do a limited amount of computation, but has seen some sequence of output from the stream cipher, can't guess the next bit with probability better than $1/2 + n/2^k$, where $n$ is the number of times they can evaluate the stream cipher within their computational limits.
The adversary's state of knowledge has min-entropy $k$ bits in this case: the key is one of $2^k$ possibilities, and each possibility has equal probability $1/2^k$ as far as the adversary knows. Without knowing any cryptanalytic technique to break the stream cipher, the adversary's best strategy is to guess the key correctly with $1/2^k$ chance of being right, compute the stream cipher, check to see whether it produces the observed outputs, and if so guess the next bit it produces; if the key is wrong, the adversary's guess for the next bit is no better than a fair coin toss.
This strategy sounds stupid. But statistical tests of random number generators such as dieharder use an even stupider strategy than what the adversary's best strategy is in the generic case: they hypothesize some generating process with simple deviations from uniform, such as a different frequencies of one bits and zero bits, and typically perform a frequentist statistical test for the hypothesis. These tests are stupider because unlike the best generic attack on a stream cipher, they are written without even the generic knowledge that the output is produced by a stream cipher with an unknown key that a smarter adversary could evaluate with any candidate key.
Sometimes cryptanalysts find better attacks. For example, within days of the original publication of RC4 on sci.crypt, Bob Jenkins reported, in a post dated 1994-09-16 with message-id [email protected], a technique to predict the next bit with significantly better probability using a computation that was possible to do on a 1994-era laptop—thus breaking RC4, which would go on to be used in practice for two decades before anyone in a position to make decisions decided that it was a bad idea for TLS. But seldom is a seriously proposed stream cipher so hopelessly broken that generic statistical tests for random number generators like dieharder make a better attack.
In cryptography engineering, it is expedient to treat every $\ell$-bit output of a secure stream cipher under a key not known to an adversary as if the adversary's knowledge of it had, a priori, at most $\min(\ell, k)$ bits of min-entropy independently. This abuse of language is justified because a real computationally bounded adversary's best guess about the stream cipher output is, in practice, essentially the same as if it really were $\min(\ell, k)$.
We usually choose $k$ so that $n/2^k$ is negligible for any realistic values of $n$—e.g., if we pick $k = 100$, then we probably thwart any adversary whose energy budget for computation isn't enough to boil Lake Geneva. Standard cryptography errs on the side of safety by picking $k \geq 128$. Sensible cryptography also avoids multi-target attacks and potential future quantum cryptanalysis by picking $k \geq 256$.
Starting at the end, high entropy (unpredictability) can mean two things with a key stream generator.
Firstly, you can measure the entropy of the generated bit stream coming out of your code. If it's maximum, it's 1 bit /bit, 8 bits /byte or 100% depending on your measurement scale. I take it you allowed for the stream being ASCII rather than binary. These entropy values will mean that your stream is totally random and unbiased. I'm unfamiliar with cryptool, but I hope that it doesn't use the basic Shannon entropy formula as that doesn't really work if there's any form of correlation within the test sample. I've only found compression estimation to be reliable for unknown data samples. Bias /correlation allows prediction which broke the RC4 cipher. Not sure how you determined periodicity. That can be very hard and is not always evident by inspection. And empirically measuring periodicity can also be very difficult.
If you have a sufficiently large sample of (binary) stream data, you could use something like dieharder to check the entropy quality of data. Even ent is reasonable for files up to 2GB.
Secondly, there's the entropy of the seed for the generator. Random looking output is useless if your generator started from a 32 bit seed. That would mean there were only 2^32 possible sequences at best. With bad seeding /algorithm Finney like states (RC4) can develop truncating the length of the output cycles. Consequently, the maximum cycle from a 32 bit seed might only be 2^16. So it is suggested that the seed for the generator should be at least 128 /256 bits of entropy. If you can't input this directly and are using seeds like "My birthday" then you should at least use a key derivation algorithm like Argon2 or bcrypt to introduce a long time delay trying when trying to brute force your password.
It's also surprisingly difficult to determine the entropy of a password. The difficulty extends well beyond the simple algebraic calculation of it's entropy. Social and psychological factors come into play as well as which characters you used, or how many letters. This is where social engineering attacks can be successful.
output has a close to maximum entropy value- what do you mean byentropy value? And how are you measuring it? $\endgroup$