As my first blog post of 2021 (I’m going to try and write a blog post once a month), I’d like to talk about Kryptor v3 Beta. This is the next version of my free and open source file encryption software that will hopefully be released in February.

My goals for what Kryptor should be have changed. Kryptor was originally inspired by how VeraCrypt was designed. I wanted to give the user choice. However, as I’ve continued to learn about cryptography, I’ve come to realise that choice is a very bad idea. The software becomes reliant on the user making wise decisions rather than it being secure by default.

In response to this realisation, I’ve designed Kryptor v3 to be more like age. However, I decided to take things further and implement Minisign like functionality. The result is a mix of the two tools with some improvements and limitations, and I think this is a good thing since a common complaint is that you shouldn’t have to download separate tools for file encryption and file signing. I just need to ensure that I don’t go overboard with features.

Now that the intro is out of the way, here’s a breakdown of what you can look forward to:

  • Chunked AEAD: XChaCha20-Poly1305 with 16 KiB chunks. This change has several benefits - for example, errors are detected early, and the file only has to be processed once rather than twice, meaning improved performance.

  • Fixed Argon2 parameters: A memory size of 256 MiB and 12 iterations. This is equivalent to about 1-1.2 seconds of delay, depending on the machine. I’m hoping I can get away with 256 MiB of RAM since most machines have at least 8 GB nowadays.

  • Faster folder encryption: The new design uses a KEK/DEK model, meaning much faster folder encryption since password-based key derivation only occurs once for an entire folder. Each file gets encrypted with a random key.

  • Authenticated asymmetric file encryption: Unlike in age, the asymmetric (technically hybrid) encryption is going to be authenticated. This means that an attacker can’t replace the ciphertext, but the sender can’t decrypt the encrypted file. The downside of this approach is that user input is more complicated, but authentication is important. Note that age is probably still preferable for multiple recipients since you have to encrypt the same file multiple times to send it to multiple people with Kryptor.

  • Masked password entry: Password entry is now hidden like on Linux. Passwords are also stored in char arrays instead of as strings, allowing the password to be cleared from memory. You can leave the password entry blank to randomly generate a random passphrase.

  • File signing: Kryptor uses a simplified Minisign format for detached signatures. You can specify a public key as a string or a file, whereas private keys can only be specified as a file.

  • Private key encryption: XChaCha20-Poly1305 and Argon2id are used to protect generated private keys with a password.

  • Exporting key pairs: When you generate a new key pair, the public key is displayed as a Base64 string in the terminal as well as being exported to a .public file. The encrypted private key is exported to a .private file.

  • Code improvements: I have rewritten most of the program. I’ve reorganised the folders, made more classes, split up subroutines, and improved the performance of certain portions. I’ve also switched to .NET 5. All of this means better performance and more readable, maintainable code. It’s not perfect, but it’s a lot better.

  • GitBook documentation: I’m rewriting the documentation on GitBook. This will make the documentation a lot easier to read and save me some money if I stop paying for Neocities. However, I’m not sure what I’d do about this blog if I did that.

Now for the bad news. I don’t intend to continue developing the GUI version. I know, I know. The GUI version is where it all started, and it’s also pretty easy to use. Plus, Windows users love a good GUI, and I understand why. Here’s my reasoning:

  1. The new functionality is very tricky to implement with a GUI. Things like offering file encryption using asymmetric keys becomes complicated when you can enter the public key as a string or select a public key file.

  2. The GUI version isn’t cross-platform. Windows Forms makes it very easy to produce a GUI program for Windows. By contrast, cross-platform GUI development is a lot more difficult - e.g. you need to learn another language just to write the GUI! I don’t know why there aren’t more drag and drop solutions.

  3. I don’t want to have to work on two projects at once. I could make a code library for the main code, but this wouldn’t completely solve the problem (see point 2). It’s a lot easier to just work on one version of the program.

  4. Having different versions makes downloading the program a bit more confusing. A minor point but still worth a mention.

That will wrap up this blog post. If you’re interested in the technical details, then you can check out the GitBook documentation here. Note that some of these details aren’t final; I’m still changing certain things. Feel free to email me with any feedback on the design or documentation.