<div dir="ltr">The simplest error correction code is a repetition code. This has escaped many peoples attention.<div><br></div><div><a href="https://eprint.iacr.org/2017/382">https://eprint.iacr.org/2017/382</a><br></div><div>" The frequency at which a key
should be changed in order to maintain an minimum level of protection depending on the
number of unrolled rounds computed per cycle is explored."</div><div><br></div><div>Here some attacks were made against Simon and Speck.</div><div><br></div><div>In my lay opinion, RC4 is more secure for the internet of things. The greatest vulnerability for computers is memory bound errors, not... uh. Malicious javascript sending a DDOS on an 100 megabit uplink to a server so a passive adversary can collect ciphertexts and do statistical analysis. Naturally everyone says that no one was fired for using AES, but who was fired for not putting a password on a database?</div><div><br></div><div>I think if the RC4 round function was applied key length bytes more times (128-bit key, 16 more key schedule rounds), the first few bytes will have less bias, and the only related key recovery attacks apply to the first few bytes.</div><div>An additional xor to mask the output or input of a byte lookup may improve things.</div><div>Or use an ARX cipher as a NLFSR, like the Lex cipher.</div><div><br></div><div><br></div><div>In any case, don't use error correction codes in cryptography.</div><div><br></div><div><br></div><div>This is some kinda multidimensional chess.</div></div>