The author reminds of some religious people I've had debates with in the past. They would make some fundamentally flawed argument, get shot down, and so they would move on to other arguments, which is not great but valid. But then, later, I'd see them making the exact same argument to someone else.

To people like this, arguing is like punching. If you punch someone and they get up, they're a "tough opponent". That doesn't mean that punching is ineffective on other people. They just don't understand at their core that once an argument is shown to be false, it can never be reused. Their mind just doesn't work this way. They think "Well, left-hook didn't work on this guy, but maybe it'll work in that guy" or "This guy didn't fall for this argument, but maybe that guy will."

It's deeply dishonest, but I'm not convinced they're even aware of this.

So, just from a cursory look at his code, the glaring problems I see are:

1) It'll crash if you feed it more than 256MB because of the way the C# BitArray class works. He's also using 32-bit ints in several places that have similar issues. These are implementation details, but it just goes to show how thoughtless the "reference implementation" is.

2) Similarly, the reference implementation copies the entire data into the BitArrary (and then back into a byte array) for each "round". This is spectacularly inefficient. He never mentions throughput in terms of MB/s/GHz or any such thing. I wonder why...

3) It's not a stream cipher. You need to encrypt the entire file. Again, he could come up with some sort of streaming version by feeding in the last few KB of the previous encrypted chunk into the next chunk, but he hasn't. As the long history of various streaming ciphers have shown, this is actually a hard problem to solve efficiently and securely. This is why AES-GCM is the hot new thing: it's both.

4) If either the key or salt values are all 0s then the encryption does nothing. AES for comparison will still encrypt your data with some level of security even if the IV initialisation is not perfectly random or skipped.

5) He's calculating the offsets as an "int" from a byte multiplied by a byte. Hence the maximum shift is 65536 positions. This is just big enough to exceed L1 data cache on most platforms, but have a high hit ratio. Whether you hit the L1 cache or not depends on the Key & IV values, so this is a recipe for timing-based side-channel attacks. Constant-time cyphers are basically mandatory these days...

6) Related to the above: The bit shifts are only in an 8KB window, but the byte shifts are in an 64KB window. I wonder if there's some interaction here where this might make some keys insecure.

7) Despite this windowing, the default "protocol" wraps around the end of the file to the beginning using a modulo the data.Length, so it can't be used as a streaming cipher. To do so, he'd have to introduce a breaking change.

8) The encryption is defined in terms of bit-by-bit and byte-by-byte long-range operations, so there's basically no hope of ever making this efficient. E.g.: with SIMD or similar many-bytes-at-a-time instruction sets. The "state" that would have to be kept in CPU registers is over 64KB, so this is just never, ever, EVER going to compete with something like AES-NI.

I could go on, but I'm wasting my time. This is wasting everyone's time.

The author clearly has no interest in producing something that is secure and usable. He's just enjoying the arguments. He's even posted some of the feedback on his GitHub, proudly showing off the debates he's felt he's won.

Don't feed this troll.