Is continual breaking changes with no option for backwards compatibility planned for Kryptor?

[a-528]

There has already been breaking changes, and more are planned. Should we expect future versions to continue to be incompatible with files created in older versions?

Similar tools have made statements on this. 'Picocrypt' is very averse to breaking changes for past files, and 'age' has stated everything past 1.0.0 will be backwards compatible.

I know the goal of the project is a simple code base, but having continual breaking changes removes a huge chunk of potential use cases. If I were to guess, a decent chunk of Kryptor users utilize it for encrypting files for themselves, probably often with the passphrase option.

Personally, I don't see myself continue use of Kryptor, if my files risk being incompatible years down the road. Some files are put away for years and it isn't possible to keep these in an up-to-date format.

Making a clear statement on intents for keeping backwards compatibility or not, would be a benefit for future users.

[samuel-lucas6]

This is a good question. Obviously, I would prefer to make things backwards compatible for that reason. However, that isn't feasible if you want to improve on a protocol. A good example is adding support for post-quantum algorithms or correcting design flaws like Unicode normalization. A statement like 'this will always be backwards compatible' either means you're extremely confident there are no issues with the protocol or you'll never fix certain flaws, and other projects aren't perfect either (nothing is).

The other thing to note is that Kryptor now uses an indistinguishable from random file format. Therefore, there are no version numbers to allow extra code for backwards compatibility. You can't even identify if a file was encrypted by Kryptor from looking at the contents. This is very different to most tools, which make no attempt to do this.

With that said, I haven't been very active on this project for a while due to other projects/things going on. There shouldn't be any breaking changes for a long time because they'll get grouped together and libsodium won't add support for post-quantum algorithms for ages I expect. Then I have to actually read about things and design a new protocol, which is a massive amount of work with the post-quantum stuff.

Furthermore, I'd like to create another file encryption tool that's simpler than Kryptor and symmetric crypto only. The aim of that project would be to have no breaking changes and no new features. Basically a one and done of how to do file encryption properly, a bit like Encpipe. However, there will be some complexity as it would be good to support YubiKeys, padding/a random file format like in Kryptor, and stream encryption. I have no idea when I'll get around to doing this as I've been prioritising implementing cryptographic constructions/algorithms for learning purposes.

I'll finish by saying fair enough if you don't want to use Kryptor for that purpose. The mitigation with Kryptor would be to keep a backup of the executable and source code of the version used to encrypt files. The .NET version will eventually go out of support, but it would likely be as simple as editing the .NET version and rebuilding.

I'll add a comment to the Goals section of the website about backwards compatibility.

[a-528]

Thank you for the thorough answer.

I don't know how much it'd impact the code base, but could it be possible to add something like --compatibility [--version 4], where Kryptor would try all previous algorithms, or use the one passed as a parameter? Maybe output which version/algorithm was used, if --compatibility is used without a specific version, for the users future reference.

Your approach of no user influence on the algorithm and constants used, must make this easier to implement. Not easy, but easier and very possible.

[samuel-lucas6]

That would theoretically be possible but a nightmare to implement at this point. It would also add a bunch of complexity and code that can then never be removed for very little benefit. Nobody should be using anything prior to v4 at this point.