Add Dexios as a command-line file encryption tool

[brxken128]

Disclaimer: I wrote this tool!

It's called Dexios! I've been working on it for almost a month, and it's finally at the point where I'm happy to share it with people.

It offers secure, authenticated and fast command-line file encryption of files. It's written entirely in Rust, and is entirely open source. The encryption libraries used have received audits (excluding Deoxys).

It uses XChaCha20-Poly1305 by default, with the option for AES-256-GCM. There's also another option for Deoxys-II-256, but it's not ideal and there are many warnings in place surrounding it's usage.

Password hashing is done via argon2id. There's support for a keyfile, entering a password within the terminal and a DEXIOS_KEY environment variable. The argon2id parameters are hard enough to be secure, but low enough to be portable and used on a wide range of devices (m = 256MiB, t = 8, p = 4)

• There's a file "shredding" command, but I feel as though this needs to be kept as another function of my tool calls for it.
• There's also a hashing/checksum command, which uses BLAKE3 as an additional layer to ensure the file is exactly the same. Within Dexios, it can be enabled to hash the encrypted file, for the user's peace of mind. There is also a standalone hashing mode, which can be used on any file.
• There are functions for manipulating the headers of encrypted files. You may dump/extract a header to another file, you can strip the header completely, and you are able to subsequently restore them. There's even an option for decrypting from a detached header, if you'd prefer to store them separately.
• It uses a dexios-core library to isolate the cryptographic functions from the user-facing application. This makes it easier to manage security-critical features, and was added in v8.5.0

It can encrypt in both STREAM mode (using a 31-bit little-endian counter), and by loading things into memory. Streaming modes are used for encrypting all files, and "memory" mode was kept in place for backwards-compatibility. Dexios' streaming implementation works perfectly for files less than 1MiB (the block size), so it is now the default for encrypting all files.

I've worked quite hard to get it both stable, and performant. I believe it hits both marks entirely.

It can encrypt Fedora-Workstation-35-1.2.aarch64.raw.xz (3.5GiB) in 5˜ seconds, and that's limited by the speed of my SSD.

It is supported on Windows/Linux/FreeBSD/Android - Windows support was added in v8.3.0

I believe the PrivacyGuides section on file encryption software is rather populated, so I get if you'd rather not add another to the list.

Link to the repos: https://github.com/brxken128/dexios https://github.com/brxken128/dexios
Link to the docs: https://brxken128.github.io/dexios/
Link to the technical details: https://brxken128.github.io/dexios/dexios-core/

I'm open to any questions, criticism, or suggestions!

[ghost]

You can post a link to your project and see what people think. Even if it doesn't get added initially if there's a discussion about it it can be reevaluated later on.

[samuel-lucas6]

Great job with all the documentation and effort that's been put in. A few things that jumped out at me without glancing behind the scenes, which I couldn't do properly anyway because I despise the readability of Rust:

• What's the rationale for supporting XChaCha20-Poly1305, AES-GCM, and Deoxys-II? Deoxys-II doesn't seem to be recommended by you anyway, so I would argue that should definitely be removed. Then I would continue to argue that only XChaCha20-Poly1305 should be supported. The main reason to support both AES-GCM and (X)ChaCha20-Poly1305 is when you want the speed boost with hardware support and ChaCha20 for when support isn't available. That's not really relevant here.

• Is the header being authenticated?

• Have you considered doing the 'packing' without compression? Compression should be slower and generally isn't recommended alongside encryption.

• What parameters are being used for Argon2id?

• How is the keyfile processed before it becomes the encryption key?

• Is it necessary to store that memory mode/stream mode is being used? Couldn't that be determined from the file size?

• I would recommend trying to make the program cross-platform. Most PrivacyGuide visitors are Windows users. It's also problematic if you ever switch OS, like I switched back from Linux after having freezing difficulties for months.

• Can you encrypt multiple files at once aside from specifying a directory? I think this flexibility is nice to have.

• Do you have to specify the name of the output file? Most of the time, this is an unnecessary user input.

Sorry if I missed something, but I haven't currently got much time.

[brxken128]

• What's the rationale for supporting XChaCha20-Poly1305, AES-GCM, and Deoxys-II? Deoxys-II doesn't seem to be recommended by you anyway, so I would argue that should definitely be removed. Then I would continue to argue that only XChaCha20-Poly1305 should be supported. The main reason to support both AES-GCM and (X)ChaCha20-Poly1305 is when you want the speed boost with hardware support and ChaCha20 for when support isn't available. That's not really relevant here.

I added Deoxys support as I believe it has the potential to replace some of the other algorithms. I do not recommend it, you're right, but it has an amazing track record thus far - the only thing that's lacking is a good implementation.

• Is the header being authenticated?

It's authenticated in the sense that Dexios will fail if it's not valid, but there are no cryptographic checks against it.

• Have you considered doing the 'packing' without compression? Compression should be slower and generally isn't recommended alongside encryption.

Yes, I had plans to remove the compression entirely for the release of v8.3.0. It's pretty slow and unnecessary also.

• What parameters are being used for Argon2id?

Not hard enough, I'll admit. I can't remember them off the top of my head. Either way, they're going to be bumped up in v8.3.0 as it'll require an iteration of the header version. If you have any parameter recommendations, I'd love to hear them as I can't seem to find a good balance on memory usage and such. I only have a couple of machines to test with and they're both pretty powerful (and not a good baseline).

• How is the keyfile processed before it becomes the encryption key?

It goes straight into argon2id. I don't believe this to be an issue as argon2 uses an inner-hashing function akin to BLAKE2 - I'd be happy to be corrected here though.

• Is it necessary to store that memory mode/stream mode is being used? Couldn't that be determined from the file size?

This is how prior versions handled it, but I think it's much easier to just store that data within the header. It allows for more flexibility this way too.

• I would recommend trying to make the program cross-platform. Most PrivacyGuide visitors are Windows users. It's also problematic if you ever switch OS, like I switched back from Linux after having freezing difficulties for months.

You make a great point, I can definitely get to work on Windows. It shouldn't be too hard to migrate as there's only a few things that I can see being problematic within my code.

• Can you encrypt multiple files at once aside from specifying a directory? I think this flexibility is nice to have.

Not currently - I left this up to the find utility as I couldn't figure out a user-friendly way to do it but I can add this to the v8.3.0 roadmap!

• Do you have to specify the name of the output file? Most of the time, this is an unnecessary user input.

I was going to implement an automatic extension, and I suppose this could tie into the encrypting multiple files at once.

Sorry if I missed something, but I haven't currently got much time.

I believe you got everything! I love what you've done with Kryptor, and I hope our projects can co-exist in a friendly manner. Good luck in your exams :)

[samuel-lucas6]

I added Deoxys support as I believe it has the potential to replace some of the other algorithms. I do not recommend it, you're right, but it has an amazing track record thus far - the only thing that's lacking is a good implementation.

Interesting, I should read about it properly. I expect AEGIS and OCB are likely going to get the most use. Is AES-GCM just there for its performance?

It's authenticated in the sense that Dexios will fail if it's not valid, but there are no cryptographic checks against it.

I suggest using at least parts of the header as additional data. Things like version numbers, modes, and empty space should be authenticated. No modification should be allowed anywhere without it leading to a decryption error.

Yes, I had plans to remove the compression entirely for the release of v8.3.0. It's pretty slow and unnecessary also.

The ZIP idea is a good one.

Not hard enough, I'll admit. I can't remember them off the top of my head. Either way, they're going to be bumped up in v8.3.0 as it'll require an iteration of the header version. If you have any parameter recommendations, I'd love to hear them as I can't seem to find a good balance on memory usage and such. I only have a couple of machines to test with and they're both pretty powerful (and not a good baseline).

The Argon2 RFC recommendations in case you haven't seen are:

1. t=1, m=2 GiB (default)
2. t=3, m=64 MiB (memory-constrained/interactive)

Libraries like libsodium and Monocypher use a parallelism of 1. I think a memory size of 128-512 MiB is probably ideal because using 1+ GiB could be a bit much depending on the system. Then an iteration/passes count of 3+ to make up for the lower memory. I went with 256 MiB and 12 iterations because it seemed to be around or just over 1 second on my system. Much more delay and it could be annoying. I also haven't done proper benchmarking on slower hardware though. Age seems to have virtually no delay at all because the scrypt parameters are quite low.

It goes straight into argon2id. I don't believe this to be an issue as argon2 uses an inner-hashing function akin to BLAKE2 - I'd be happy to be corrected here though.

That sounds fine. If the keyfile is high in entropy, then it's technically overkill and hashing would make more sense from a performance perspective.

This is how prior versions handled it, but I think it's much easier to just store that data within the header. It allows for more flexibility this way too.

Fair enough.

You make a great point, I can definitely get to work on Windows. It shouldn't be too hard to migrate as there's only a few things that I can see being problematic within my code.

I'd say it's worth it. Coming across a cool program and then discovering there are only Linux installation methods is annoying for us Windows users.

Not currently - I left this up to the find utility as I couldn't figure out a user-friendly way to do it but I can add this to the v8.3.0 roadmap!
I was going to implement an automatic extension, and I suppose this could tie into the encrypting multiple files at once.

Cool cool.

I believe you got everything! I love what you've done with Kryptor, and I hope our projects can co-exist in a friendly manner. Good luck in your exams :)

Thanks! Getting near the end now. More alternatives to age is a good thing in my opinion. It's just easy to make mistakes with these things that's the trouble.

[brxken128]

Interesting, I should read about it properly. I expect AEGIS and OCB are likely going to get the most use. Is AES-GCM just there for its performance?

Perfomance, and it's just what some people like. The NIST recommend it heavily, so I don't really blame people if that's their cipher of choice.

I suggest using at least parts of the header as additional data. Things like version numbers, modes, and empty space should be authenticated. No modification should be allowed anywhere without it leading to a decryption error.

I've added this, with HMAC (my other reply has the specifics)

The Argon2 RFC recommendations in case you haven't seen are:

1. t=1, m=2 GiB (default)

2. t=3, m=64 MiB (memory-constrained/interactive)

Libraries like libsodium and Monocypher use a parallelism of 1. I think a memory size of 128-512 MiB is probably ideal because using 1+ GiB could be a bit much depending on the system. Then an iteration/passes count of 3+ to make up for the lower memory. I went with 256 MiB and 12 iterations because it seemed to be around or just over 1 second on my system. Much more delay and it could be annoying. I also haven't done proper benchmarking on slower hardware though. Age seems to have virtually no delay at all because the scrypt parameters are quite low.

This is a good point, I do have my memory still quite low, all things considered. 512MiB sounds like a good balance, I'd need to do more testing though. I had it set rather high and it was taking 12ish seconds on my 3700x, so I bumped it down a lot. Tweaking them is always a pain.

It goes straight into argon2id. I don't believe this to be an issue as argon2 uses an inner-hashing function akin to BLAKE2 - I'd be happy to be corrected here though.

That sounds fine. If the keyfile is high in entropy, then it's technically overkill and hashing would make more sense from a performance perspective.

I can't always confirm that the keyfile will be high-entropy, so I believe the trade-off there is more than okay as it'll protect users who use not-so-ideal keyfiles.

I'd say it's worth it. Coming across a cool program and then discovering there are only Linux installation methods is annoying for us Windows users.

I have Windows now supported, for the most part. My other reply details the specifics but I'd need to know more about WinAPI to prevent echoing the entered password to the terminal - keyfiles and environment variables still work great.

Thanks! Getting near the end now.

I'm glad that they're almost over, and I hope you get the results you were after :)

More alternatives to age is a good thing in my opinion. It's just easy to make mistakes with these things that's the trouble.

Definitely! This has been a pretty long experience of learning, and I'm glad I stuck with the random idea I had about a month ago.

Thank you for the insight into all of this - another pair of eyes truly never hurts.

[brxken128]

Taking @samuel-lucas6 suggestions (apologies for the ping), Dexios v8.3.0's changelog is as follows:

• Hardened argon2id parameters considerably
• Windows is now supported (mostly)
• SHA3-512 HMAC sign and verify the headers using the spare 16 bytes we had available - decryption will fail if the signature doesn't match (this is compatible with older files still)
• Fix paris output where newlines would not be added (this involved removing all of the "loading..." features)
• Remove compression altogether from pack modes

Thank you for the advice and I hope this resolves some of the potential issues you highlighted with my program.

[samuel-lucas6]

Perfomance, and it's just what some people like. The NIST recommend it heavily, so I don't really blame people if that's their cipher of choice.

Alright. If you're sure you want to support multiple ciphers, I wouldn't go over 3. AEGIS would be significantly better for security and performance, so you might want to reconsider if it gets standardised. Algorithms like Rocca are also promising.

I've added this, with HMAC (my other reply has the specifics)

What made you choose HMAC over just using the header as additional data? That would save some storage space, complexity, and performance cost.

This is a good point, I do have my memory still quite low, all things considered. 512MiB sounds like a good balance, I'd need to do more testing though. I had it set rather high and it was taking 12ish seconds on my 3700x, so I bumped it down a lot. Tweaking them is always a pain.

Looks like you had it set to 32 MiB, which is more appropriate if Argon2 is running on a server. On a desktop, 64 MiB should really be the minimum I'd say. No idea what settings you're using to reach 12 seconds.

I can't always confirm that the keyfile will be high-entropy, so I believe the trade-off there is more than okay as it'll protect users who use not-so-ideal keyfiles.

That was my logic as well. Could be possible to reject low entropy keyfiles as an alternative.

I have Windows now supported, for the most part. My other reply details the specifics but I'd need to know more about WinAPI to prevent echoing the entered password to the terminal - keyfiles and environment variables still work great.

Awesome.

I'm glad that they're almost over, and I hope you get the results you were after :)

Thank you.

Definitely! This has been a pretty long experience of learning, and I'm glad I stuck with the random idea I had about a month ago.

Yeah this sort of thing is a good learning experience.

[brxken128]

Alright. If you're sure you want to support multiple ciphers, I wouldn't go over 3. AEGIS would be significantly better for security and performance, so you might want to reconsider if it gets standardised. Algorithms like Rocca are also promising.

I agree - AEGIS is extremely fast from what I've seen, it's just trying to find an implementation that's compatible with my current codebase that's going to pose a challenge. I could probably depreciate Deoxys over the course of a few versions once I find a good AEGIS implementation.

What made you choose HMAC over just using the header as additional data? That would save some storage space, complexity, and performance cost.

Flexibility. I had some unallocated bytes within the header anyways, and the computation time for verifying the header is negligible. It may also complicate my streaming implementation, as I haven't tinkered around too much the "associated data" half of AEADs.

Looks like you had it set to 32 MiB, which is more appropriate if Argon2 is running on a server. On a desktop, 64 MiB should really be the minimum I'd say. No idea what settings you're using to reach 12 seconds.

The 12 seconds metric was from an unoptimised debugging build - it's roughly 1 second now with (m = 256MiB, t = 8, p = 4) on a release build. I played around with the parameters and had to take slower systems into account.

Once again, thank you very much for all of the suggestions, or even challenging some of my decisions. It's great to have another pair of eyes to rationalise some of your choices, imo.

Best wishes :)

[brxken128]

I thought I'd provide an update, in case anyone stumbles upon this.

• In order to decrease the potential attack surface, pack/unpack modes were removed. As we support more and more operating systems, preventing zip-slips and other issues will get harder and harder. This remains backwards-compatible as all packed directories are just zip files once decrypted. That, and I wasn't too happy with my implementation
• Windows has support, although partial (when entering a password in the terminal, it's not hidden - it still works and keyfiles/env vars work flawlessly)
• A logo (long and short) has been added to the project
• Key derivation (argon2id) parameters were hardened even further (t = 10, m = 256MiB, p = 4)
• Headers are now authenticated via AAD instead of SHA3-512 HMAC - all 64 bytes are authenticated fully with every block, at little to no extra computational cost. This decreased the attack surface, although it was quite marginal
• When decrypting a file with an older header version, a notice will be displayed to the user suggesting that they re-encrypt at their earliest convenience. I had attempted to implement an auto-update, but I couldn't add it in a user-friendly manner while also providing all of the functionality that the normal encrypt mode has to offer. I have a few thoughts on how to do this though, and I will probably add it to the v8.5.0 roadmap
• An official release cycle will be implemented
• The documentation has received further updates and information
• Binaries had specific CPU flags removed as the AEAD libraries detect and use the hardware cryptography primitives automatically, this means that release binaries will work on more systems (and Windows builds were added to Github actions)
• The code was cleaned up massively. Lots of repetition was removed and generalized, and I added the same enum-based approach to memory mode that we used for streaming modes
• The docs should receive major additions
• Support for multiple languages will be implemented in due course. It's not high up on my list, due to how large of a task it will be to translate and add all of the functionality, but it is planned nevertheless

I believe those are the major changes worth covering - once again, I'm open to any questions or criticism!

Thank you for your time.

[brxken128]

Some changes have been made recently, these include:

A TL;DR:

• A header design that has support for multiple keys to unlock one file
• Complete Windows support
• Major codebase cleanups
• Deoxys-II-256 was deprecated for encryption until the library upstream is improved (performance-wise).
• Both BLAKE3-balloon and argon2id key hashing. BLAKE3-Balloon was made the default due to concerns over argon2i, and argon2 as a whole
• Thorough tests that are performed via Github actions, and unit tests were written
• Support for Windows, Linux, MacOS, FreeBSD and Android
• A GUI application is now in the works too
• Pack mode was improved, and now has support for ZSTD
  • I fully trust this implementation. Compression with encryption isn't recommended, but that's only in cases where an attacker has control over the input. In this case (local, cold-file encryption) there should be minimal risk. No compression is still default.
• Passphrase autogeneration was implemented
• A marginally more secure RNG (ThreadRng as opposed to StdRng)
• Command-line output was massively cleaned up, and Dexios is now more UNIX-like (mostly print-on-error only)
• Dependencies were cleaned up
• Better error handling on failure (mostly the cleaning up of temporary files in pack mode)
• You may now change, delete and remove keyslots
• You can also view the details of an encrypted file

There are a few other minor changes, but I believe this is most of them.

[brxken128]

I'm wondering why you've chosen to go with 3 words from the EFF large list and 6 digits, instead of adding additional words, as is the standard. I think it would make a lot more sense to stick with that, as the security it provides is well known and easily calculated.

In our introductory password page that I wrote, we recommend that people choose a 7 word diceware passphrase: https://www.privacyguides.org/basics/passwords-overview/#diceware-passphrases

If I'm being honest, I wasn't aware that a 7 word passphrase such as this was the standard - it does make a lot of sense though!

I think with the one-second password hash duration, and the inconceivable amount of combinations with either methods, more than enough security is provided (even if an attacker is equipped with specialized hardware). I would be more than happy to change this functionality, and move to the 7 word passphrase if needed.

[matchboxbananasynergy]

I'm wondering why you've chosen to go with 3 words from the EFF large list and 6 digits, instead of adding additional words, as is the standard. I think it would make a lot more sense to stick with that, as the security it provides is well known and easily calculated.
In our introductory password page that I wrote, we recommend that people choose a 7 word diceware passphrase: https://www.privacyguides.org/basics/passwords-overview/#diceware-passphrases

If I'm being honest, I wasn't aware that a 7 word passphrase such as this was the standard - it does make a lot of sense though!

I think with the one-second password hash duration, and the inconceivable amount of combinations with either methods, more than enough security is provided (even if an attacker is equipped with specialized hardware). I would be more than happy to change this functionality, and move to the 7 word passphrase if needed.

What I think would make sense is to default to something like a 6 or 7 word diceware passphrase, but ideally have people be able to adjust the number of words the passphrase contains (taken from the same EFF large wordlist in a random manner).

You would essentially be including a bundled in diceware passphrase generator in that case.

[brxken128]

I just added this feature, and a generated passphrase now looks like Distrust-Ninth-Dental-Coveted-Generic-Streak-Setting. I opted to keep the - in order to avoid confusion in a terminal environment, but it's a pretty simple change if the spaces would be more suitable.

[matchboxbananasynergy]

That looks great! I suppose that the "-" between words makes sense in a CLI context. I actually answered a question where someone was asking about capitalization in diceware passphrases, which you might want to talk a look at: https://github.com/privacyguides/privacyguides.org/discussions/1784

It seems to me that what little bit of entropy it adds isn't worth the hassle of having to remember to capitalize them when inputting the passphrase. If people require more security, I think it always makes the most sense to just add another word, as the entropy that adds (~12.9 bits) with the list you're using is substantially higher.

Disclaimer: These are just my thoughts and opinions from what little I know, you shouldn't feel compelled to adjust Dexios based on what I say in the slightest. I am mostly just trying to ask questions to understand the reasoning behind your decisions.

[brxken128]

That also does make fair amount of sense, and having to capitalize the words each time is a hassle (and it's evidently not too beneficial).

I do quite like this change, and it'll probably make some lives easier, so I'll implement it. Thank you!

[dngray]

I've been having a look through the documents for this. The Rust implementation for this has been audited as @brxken128 points out https://brxken128.github.io/dexios/Introduction.html#security-notices

I noticed the site said:

Dexios will continue to receive updates. Things are stable for the time being and I consider none of the code broken. In the (somewhat) near future I plan to change the backend entirely and give the CLI a re-write, so that things are both easier to maintain and understand. This will regrettably not be backwards-compatible, but the performance improvements and stability guarantees will be extremely worthwhile.

We might want to re-evaluate this after the re-write.

Also just as a note, we're deprecating Github discussions, and instead use a proper forum https://discuss.privacyguides.net/.