New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
discussion: size-dependent fuzz? #24
Comments
Hi, @aaannndddyyy. A few thoughts:
So basically, yes, I think this is a good idea, if done right, but would like to finish the tweaks related to issue #17 first. Although it might not be clear from the discussion there, I'm considering taking @maqp's advice and just getting rid of one of the two fuzz sides, because (especially right now with a 0-512 limit on fuzz) there is no meaningful gain from disguising the position of the plaintext within the overall encrypted message: it's not solving a real problem, as long as the pad is really random OR the plaintext is not a known plaintext, and even if it were solving a problem, it's only making it at most 512 iterations harder to solve that problem, which is not very much for a computer. |
If i see it correctly, by only reading 2 bytes for determining the fuzz size, 2^(2_8) numbers can be encoded. the modulo is for cutting it down if the number grows beyond a limit you set. 2^(2_8) bytes of fuzz is not much. Re "it's only making it at most 512 iterations harder to solve that problem, which is not very much for a computer.", see my comment on issue #17 |
Would it make sense to optionally make self._default_fuzz_source_length and self._default_fuzz_source_modulo determined by the length of the plaintext ?
Thus the fuzz could be always between 0 and a fixed percentage of the lengths, instead of always between 0 and 511, no matter how big the file gets.
WOuld be codewise trivial, but would it be worth burning more pad ?
The text was updated successfully, but these errors were encountered: