🆕 Software Suggestion | Kryptor #2064

New Issue

2020-09-21T18:56:46Z

samuel-lucas6 commented

2020-09-21 18:56:46 +00:00

(Migrated from github.com)

Basic Information

Name: Kryptor
Category: File Encryption
URL: https://kryptor.co.uk/ & https://github.com/Kryptor-Software/Kryptor

Description

Kryptor is free and open source file encryption software for Windows, Linux, and macOS. There's an installable and portable version for Windows, and it's semi-portable on Linux & macOS - it requires Mono to be installed because it's written in C# Windows Forms.

File encryption supports XChaCha20 (default setting), XSalsa20, or AES-CBC. Argon2 is used for key derivation, BLAKE2b is used as the MAC, and BLAKE2b is used for all hashing. There's a unique 256-bit encryption key and 512-bit MAC key per file. No keys are ever reused. The cryptography relies on the libsodium library and the System.Security.Cryptography namespace in .NET.

You can use a password and/or keyfile for file encryption, and you can generate random 512-bit keyfiles. There's anonymous renaming of encrypted files/folders, password sharing using asymmetric encryption (libsodium Sealed Boxes), memory encryption for sensitive byte arrays, a built-in password/passphrase generator, password strength checking, auto clear clipboard after copying passwords, etc.

Kryptor runs locally and can be run offline, but there are automatic checks for updates by default using GitHub - this can be disabled in the settings. Finally, there are numerous settings that can be changed such as the Argon 2 memory size and iterations.

I know that's quite a lot of detail, but even more detail can be found on the website in the documentation. I've been writing it for some time, but it's still not quite complete.

TL;DR: Kryptor is designed with security and privacy in mind, but it's also a lot more useable than something like VeraCrypt. Kryptor version 2.0.0 Beta has now been released, which is a lot faster than version 1.

Why I am making the suggestion

Kryptor uses some of the best cryptographic algorithms available such as Argon2, which is significantly more secure than PBKDF2 and also an improvement over scrypt. BLAKE2b is being used instead of HMAC and SHA2 for hashing as it's significantly faster and a newer algorithm. Furthermore, ChaCha20 is being increasingly used instead of AES.

I wasn't completely happy with AxCrypt, Hat.sh, or Cryptomator, so I developed my own software. There are lots of features because I originally designed it as an alternative to AxCrypt specifically since AxCrypt has a paywall that restricts most of the features.

My connection with the software

I am the developer of Kryptor.

I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.

Edit: I have updated the information due to changes based on user feedback and will be updating the website's documentation again soon. Kryptor version 2.0.0 will be released soon that will contain numerous breaking changes to improve the speed of file encryption.

Edit 2: I have updated the information due to changes in version 2.0.0 Beta.

## Basic Information **Name:** Kryptor **Category:** File Encryption **URL:** https://kryptor.co.uk/ & https://github.com/Kryptor-Software/Kryptor ## Description Kryptor is free and open source file encryption software for Windows, Linux, and macOS. There's an installable and portable version for Windows, and it's semi-portable on Linux & macOS - it requires Mono to be installed because it's written in C# Windows Forms. File encryption supports XChaCha20 (default setting), XSalsa20, or AES-CBC. Argon2 is used for key derivation, BLAKE2b is used as the MAC, and BLAKE2b is used for all hashing. There's a unique 256-bit encryption key and 512-bit MAC key per file. No keys are ever reused. The cryptography relies on the libsodium library and the System.Security.Cryptography namespace in .NET. You can use a password and/or keyfile for file encryption, and you can generate random 512-bit keyfiles. There's anonymous renaming of encrypted files/folders, password sharing using asymmetric encryption (libsodium Sealed Boxes), memory encryption for sensitive byte arrays, a built-in password/passphrase generator, password strength checking, auto clear clipboard after copying passwords, etc. Kryptor runs locally and can be run offline, but there are automatic checks for updates by default using GitHub - this can be disabled in the settings. Finally, there are numerous settings that can be changed such as the Argon 2 memory size and iterations. I know that's quite a lot of detail, but even more detail can be found on the website in the documentation. I've been writing it for some time, but it's still not quite complete. TL;DR: Kryptor is designed with security and privacy in mind, but it's also a lot more useable than something like VeraCrypt. Kryptor version 2.0.0 Beta has now been released, which is a lot faster than version 1. ## Why I am making the suggestion Kryptor uses some of the best cryptographic algorithms available such as Argon2, which is significantly more secure than PBKDF2 and also an improvement over scrypt. BLAKE2b is being used instead of HMAC and SHA2 for hashing as it's significantly faster and a newer algorithm. Furthermore, ChaCha20 is being increasingly used instead of AES. I wasn't completely happy with AxCrypt, Hat.sh, or Cryptomator, so I developed my own software. There are lots of features because I originally designed it as an alternative to AxCrypt specifically since AxCrypt has a paywall that restricts most of the features. ## My connection with the software I am the developer of Kryptor. - [x] I will keep the issue up-to-date if something I have said changes or I remember a connection with the software. Edit: I have updated the information due to changes based on user feedback and will be updating the website's documentation again soon. Kryptor version 2.0.0 will be released soon that will contain numerous breaking changes to improve the speed of file encryption. Edit 2: I have updated the information due to changes in version 2.0.0 Beta.

👍 2

lynn-stephenson commented

2020-09-22 16:33:44 +00:00

(Migrated from github.com)

Looks like an interesting alternate.

Although I have a few questions:

Why did you hash the password prior to passing it to Argon2?
Why did you opt for 1024 bits instead of smaller yet still secure 128 or 256 for key file sizes?
Why did you take the ciphersuite agility approach instead of only using Libsodium's defaults?
Even with the last point, it doesn't make much sense to me to support AES in CTR and CBC mode. Why?
Why didn't you just use Blake2b for combining the password + keyfiles, it is not vulnerable to length extension attacks and adds yet another algorithm you support (HMAC-SHA-512)?

Looks like an interesting alternate. Although I have a few questions: 1. Why did you hash the password prior to passing it to Argon2? 2. Why did you opt for 1024 bits instead of smaller yet still secure 128 or 256 for key file sizes? 3. Why did you take the ciphersuite agility approach instead of only using Libsodium's defaults? 4. Even with the last point, it doesn't make much sense to me to support AES in CTR and CBC mode. Why? 5. Why didn't you just use Blake2b for combining the password + keyfiles, it is not vulnerable to length extension attacks and adds yet another algorithm you support (HMAC-SHA-512)?

samuel-lucas6 commented

2020-09-22 18:50:37 +00:00

(Migrated from github.com)

Those are all great questions.

I decided to hash the password bytes to get a fixed sized input of 512-bits. I noticed that several other programs did something similar such as KeePass.
Keyfiles are 1024-bits because that's the input that HMAC-SHA512 takes in .NET. If you provide a key less than 128 bytes (1024-bits), it gets converted to a 128 byte key, so it makes sense to just provide the correct key size.
I didn't use libsodium for everything (e.g. Argon2) because there are certain restrictions in place. For example, the Argon2 implementation in libsodium doesn't have any associated data or known secret support. If that doesn't answer your question, then please let me know.
AES-CTR has become quite popular (e.g. it's used in AES-GCM) whilst AES-CBC is becoming less popular. I wanted to give the user lots of choice, but I'll admit that it's arguably unnecessary. I originally only supported AES-CBC because I was a little concerned with implementing a custom AES-CTR. I am not recommending AES-CTR to users because of that and because it's slightly slower than the other algorithms - not especially noticeable in my testing though. Furthermore, there really isn't a reason to favour AES-CTR over XChaCha20.
I did actually switch to keyed Blake2b for combining the password and keyfile bytes at one point, but I decided to switch back to HMAC-SHA512 because HMAC allows for a larger key size, meaning more secure keyfiles (128 byte/1024-bit keyfiles). In comparison, Blake2 supports keys up to 64 bytes in the libraries I am using. HMAC-SHA512 was already being used as the message authentication code for file encryption, but I understand what you mean. Finally, HMAC-SHA512 is also not vulnerable to length extension attacks and is very robust, although SHA512 is slower than Blake2.

Edited because I misread question 2, my apologies.

Those are all great questions. 1. I decided to hash the password bytes to get a fixed sized input of 512-bits. I noticed that several other programs did something similar such as [KeePass](https://keepass.info/help/base/security.html#seckeyhash). 2. Keyfiles are 1024-bits because that's the input that [HMAC-SHA512](https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.hmacsha512.-ctor?view=netframework-4.8#System_Security_Cryptography_HMACSHA512__ctor) takes in .NET. If you provide a key less than 128 bytes (1024-bits), it gets converted to a 128 byte key, so it makes sense to just provide the correct key size. 3. I didn't use libsodium for everything (e.g. Argon2) because there are certain restrictions in place. For example, the [Argon2 implementation](https://doc.libsodium.org/password_hashing/default_phf) in libsodium doesn't have any associated data or known secret support. If that doesn't answer your question, then please let me know. 4. AES-CTR has become quite popular (e.g. it's used in AES-GCM) whilst AES-CBC is becoming less popular. I wanted to give the user lots of choice, but I'll admit that it's arguably unnecessary. I originally only supported AES-CBC because I was a little concerned with implementing a custom AES-CTR. I am not recommending AES-CTR to users because of that and because it's slightly slower than the other algorithms - not especially noticeable in my testing though. Furthermore, there really isn't a reason to favour AES-CTR over XChaCha20. 5. I did actually switch to keyed Blake2b for combining the password and keyfile bytes at one point, but I decided to switch back to HMAC-SHA512 because HMAC allows for a larger key size, meaning more secure keyfiles (128 byte/1024-bit keyfiles). In comparison, Blake2 supports keys up to 64 bytes in the libraries I am using. HMAC-SHA512 was already being used as the message authentication code for file encryption, but I understand what you mean. Finally, HMAC-SHA512 is also not vulnerable to length extension attacks and is very robust, although SHA512 is slower than Blake2. Edited because I misread question 2, my apologies.

👍 1

lynn-stephenson commented

2020-09-23 05:16:33 +00:00

(Migrated from github.com)

Sounds good. For AES in CTR & CBC mode, do you authenticate the ciphertext with a MAC?

lynn-stephenson commented

2020-09-23 05:18:23 +00:00

(Migrated from github.com)

And actually I would love to hear why you need support for AD and secret.

👍 1

samuel-lucas6 commented

2020-09-23 09:04:51 +00:00

(Migrated from github.com)

Yep, HMAC is used for authentication with all of the encryption algorithms.

The associated data allows for an easy way of preventing decryption when the wrong encryption algorithm is selected in settings. Then the known secret is basically a second salt that isn't stored with the ciphertext. Both improve the security of key derivation. It's a shame that they aren't supported in libsodium.

Another thing I forgot to mention previously is that the 'industry standard' for keyfiles seems to be 1024-bits - for example, KeePassXC uses this keyfile size. VeraCrypt also supports keyfiles up to 1 MiB.

Kryptor is designed with security in mind. It goes beyond the scope of the alternatives, which is why I developed it. I have tried to make everything as resistant to attacks as possible. The weakest link is user input (e.g. bad passwords and strings in memory).

In fact, in the case of key derivation with Argon2, it's possible that some users will complain about too much delay. I may have to adjust the default settings in the future if this is the case. The Argon2 benchmark that runs when you first launch the program chooses a delay of 250 ms or 500 ms per file depending on whether you'd prefer speed or extra security. A 500 ms delay when encrypting lots of files at once can result in a noticeable slowdown. 250 ms is a much better delay unless you're only encrypting one file at a time.

Here's a summary of key derivation in other security software for comparison:

AxCrypt
AxCrypt seems to use PBKDF2 with 1,000 iterations and a 50 ms key wrap. 1,000 iterations is far too low - that was the recommended amount in the year 2000. A 50 ms key wrap could also being increased without too much delay. This iteration count is not adjustable.

KeePass
KeePass uses AES-KDF with 60,000 iterations by default on my VM. You can change key derivation to Argon2, but the default settings are very strange. For example, they get set to 1 MiB with 2 iterations for me, which is too low. The 1-second benchmark then adjusts the iterations rather than memory size, which is not the recommended approach.

Hat.sh
Hat.sh uses PBKDF2 with 80,000 iterations, which is significantly better than AxCrypt but could still be increased. This iteration count is not adjustable unless you tweak the code. I would have set the iteration count to at least 100,000 but 80,000 isn't bad.

Cryptomator
Cryptomator uses scrypt (better than PBKDF2) with a cost parameter of 16,384 or 32,768 based on their documentation and my own vault when testing it. The block size is set to 8. These are secure interactive parameters, but they could be increased since this key derivation takes place once for the vault masterkey.

Bitwarden
Bitwarden uses 100,001 iterations on the client side and another 100,000 on the server side. The client side iteration count can be adjusted in the settings.

VeraCrypt
VeraCrypt uses 200,000 iterations for system drive encryption and 500,000 for containers and other partitions when using the default algorithm (PBKDF2 with SHA256 or SHA512). This iteration count can be adjusted by the user.

KeePassXC
Finally, KeePassXC uses Argon2 by default with a memory size of 64 MiB and 10 iterations on my VM. However, the iteration count is automatically calculated and will be different on different machines. You can also customise the Argon2 parameters.

Yep, HMAC is used for authentication with all of the encryption algorithms. The associated data allows for an easy way of preventing decryption when the wrong encryption algorithm is selected in settings. Then the known secret is basically a second salt that isn't stored with the ciphertext. Both improve the security of key derivation. It's a shame that they aren't supported in libsodium. Another thing I forgot to mention previously is that the 'industry standard' for keyfiles seems to be 1024-bits - for example, KeePassXC uses this keyfile size. [VeraCrypt](https://www.veracrypt.fr/code/VeraCrypt/plain/doc/html/Keyfiles.html) also supports keyfiles up to 1 MiB. Kryptor is designed with security in mind. It goes beyond the scope of the alternatives, which is why I developed it. I have tried to make everything as resistant to attacks as possible. The weakest link is user input (e.g. bad passwords and strings in memory). In fact, in the case of key derivation with Argon2, it's possible that some users will complain about too much delay. I may have to adjust the default settings in the future if this is the case. The Argon2 benchmark that runs when you first launch the program chooses a delay of 250 ms or 500 ms per file depending on whether you'd prefer speed or extra security. A 500 ms delay when encrypting lots of files at once can result in a noticeable slowdown. 250 ms is a much better delay unless you're only encrypting one file at a time. Here's a summary of key derivation in other security software for comparison: **AxCrypt** [AxCrypt](https://www.axcrypt.net/information/technical/) seems to use PBKDF2 with 1,000 iterations and a 50 ms key wrap. 1,000 iterations is far too low - that was the recommended amount in the year 2000. A 50 ms key wrap could also being increased without too much delay. This iteration count is not adjustable. **KeePass** [KeePass](https://keepass.info/help/base/security.html) uses AES-KDF with 60,000 iterations by default on my VM. You can change key derivation to Argon2, but the default settings are very strange. For example, they get set to 1 MiB with 2 iterations for me, which is too low. The 1-second benchmark then adjusts the iterations rather than memory size, which is not the recommended approach. **Hat.sh** [Hat.sh](https://hat.sh/about.html) uses PBKDF2 with 80,000 iterations, which is significantly better than AxCrypt but could still be increased. This iteration count is not adjustable unless you tweak the code. I would have set the iteration count to at least 100,000 but 80,000 isn't bad. **Cryptomator** [Cryptomator](https://docs.cryptomator.org/en/latest/security/architecture/) uses scrypt (better than PBKDF2) with a cost parameter of 16,384 or 32,768 based on their documentation and my own vault when testing it. The block size is set to 8. These are secure interactive parameters, but they could be increased since this key derivation takes place once for the vault masterkey. **Bitwarden** [Bitwarden](https://bitwarden.com/help/article/what-encryption-is-used/) uses 100,001 iterations on the client side and another 100,000 on the server side. The client side iteration count can be adjusted in the settings. **VeraCrypt** [VeraCrypt](https://www.veracrypt.fr/code/VeraCrypt/plain/doc/html/Header%20Key%20Derivation.html) uses 200,000 iterations for system drive encryption and 500,000 for containers and other partitions when using the default algorithm (PBKDF2 with SHA256 or SHA512). This iteration count can be adjusted by the user. **KeePassXC** Finally, KeePassXC uses Argon2 by default with a memory size of 64 MiB and 10 iterations on my VM. However, the iteration count is automatically calculated and will be different on different machines. You can also customise the Argon2 parameters.

👍 1

lynn-stephenson commented

2020-09-23 16:47:15 +00:00

(Migrated from github.com)

The security of your application is pretty good, not that I've audited it to thourghly. Although the design of it really hurts performance, and can be a PAIN if you're encrypting a large project.

The security of your application is pretty good, not that I've audited it to thourghly. Although the design of it *really* hurts performance, and can be a PAIN if you're encrypting a large project.

lynn-stephenson commented

2020-09-23 16:48:45 +00:00

(Migrated from github.com)

I'll look into the code soon, see if I can find anything. I should get have a conclusion by the end of next week after deeper analysis of design.

👍 1

samuel-lucas6 commented

2020-09-23 17:15:52 +00:00

(Migrated from github.com)

Thanks, it does need some peer review. If you find anything negative, please contact me directly via email. Your analysis of Aegis is nicely done; I look forward to hearing from you.

As for the performance, the Argon2 default parameters can be easily adjusted for future users. I think the 250 ms delay is useable, but I will admit that 500 ms is far too slow for encrypting multiple files. This is the only limitation of deriving new keys per file, but I think it's preferable to having a masterkey and key wrapping like AxCrypt does.

I've found the actual speed of encrypting files to be pretty good, although decryption is a bit slower to get started due to having to read in the trailers stored at the end of each file. There's room for optimisation and changes.

Thanks, it does need some peer review. If you find anything negative, please contact me directly via [email](https://kryptor.co.uk/Contact.html). Your analysis of Aegis is nicely done; I look forward to hearing from you. As for the performance, the Argon2 default parameters can be easily adjusted for future users. I think the 250 ms delay is useable, but I will admit that 500 ms is far too slow for encrypting multiple files. This is the only limitation of deriving new keys per file, but I think it's preferable to having a masterkey and key wrapping like AxCrypt does. I've found the actual speed of encrypting files to be pretty good, although decryption is a bit slower to get started due to having to read in the trailers stored at the end of each file. There's room for optimisation and changes.

lynn-stephenson commented

2020-09-24 07:52:34 +00:00

(Migrated from github.com)

I've found the actual speed of encrypting files to be pretty good, although decryption is a bit slower to get started due to having to read in the trailers stored at the end of each file. There's room for optimisation and changes.

I thought it was a bit odd to have the required fixed length data at the end of the file. Definitely should consider moving it to the beginning.

> I've found the actual speed of encrypting files to be pretty good, although decryption is a bit slower to get started due to having to read in the trailers stored at the end of each file. There's room for optimisation and changes. I thought it was a bit odd to have the required fixed length data at the end of the file. Definitely should consider moving it to the beginning.

👍 1

samuel-lucas6 commented

2020-09-24 10:27:07 +00:00

(Migrated from github.com)

Because the HMAC is calculated after the file has been encrypted, it's difficult to store that at the beginning of the file. So I think it's sensible appending the HMAC to the end.

However, I agree that the data obtained before encryption (the salt, nonce, Argon2 parameters) could be stored at the beginning of the file. That would be a much better solution actually than having to remove the trailers before decryption. I could just start decrypting after the headers. I feel like a fool for not doing that. I'll start looking into that. Just got to finish rewriting and checking over the documentation. It'll be a breaking change, but I don't expect many people have downloaded Kryptor yet.

Because the HMAC is calculated after the file has been encrypted, it's difficult to store that at the beginning of the file. So I think it's sensible appending the HMAC to the end. However, I agree that the data obtained before encryption (the salt, nonce, Argon2 parameters) could be stored at the beginning of the file. That would be a much better solution actually than having to remove the trailers before decryption. I could just start decrypting after the headers. I feel like a fool for not doing that. I'll start looking into that. Just got to finish rewriting and checking over the documentation. It'll be a breaking change, but I don't expect many people have downloaded Kryptor yet.

👍 1

samuel-lucas6 commented

2020-09-25 11:05:57 +00:00

(Migrated from github.com)

I've found the actual speed of encrypting files to be pretty good, although decryption is a bit slower to get started due to having to read in the trailers stored at the end of each file. There's room for optimisation and changes.

I thought it was a bit odd to have the required fixed length data at the end of the file. Definitely should consider moving it to the beginning.

Made a few code improvements so far and have a few left to do:

The Argon2 parameters, salt, and nonce are stored at the beginning of the file now (in that order). The HMAC is still stored at the end of the file.
There's now no '.backup' file created before decryption (that was used to backup the trailers that got removed).
Only the HMAC gets reappended if an error occurs now rather than all of the trailers being reappended.
I'm using a larger buffer size (128 KiB instead of 4) when reading files over 1 MiB, which leads to slightly increased performance.
I've replaced some &s with && in if statements for greater efficiency.
I've removed the 500 ms benchmark setting. I've switched the benchmark to 150 ms (fast) or 250 ms (more secure) based on user input.
Some other maintainability improvements.

Thank you for your feedback, I'd like to hear your thoughts on these changes. Do you think it would be worth adding a header to indicate that the encrypted file is a Kryptor file? Secondly, would you say a delay of 150 ms or 250 ms per file is appropriate?

> > I've found the actual speed of encrypting files to be pretty good, although decryption is a bit slower to get started due to having to read in the trailers stored at the end of each file. There's room for optimisation and changes. > > I thought it was a bit odd to have the required fixed length data at the end of the file. Definitely should consider moving it to the beginning. Made a few code improvements so far and have a few left to do: - The Argon2 parameters, salt, and nonce are stored at the beginning of the file now (in that order). The HMAC is still stored at the end of the file. - There's now no '.backup' file created before decryption (that was used to backup the trailers that got removed). - Only the HMAC gets reappended if an error occurs now rather than all of the trailers being reappended. - I'm using a larger buffer size (128 KiB instead of 4) when reading files over 1 MiB, which leads to slightly increased performance. - I've replaced some &s with && in if statements for greater efficiency. - I've removed the 500 ms benchmark setting. I've switched the benchmark to 150 ms (fast) or 250 ms (more secure) based on user input. - Some other maintainability improvements. Thank you for your feedback, I'd like to hear your thoughts on these changes. Do you think it would be worth adding a header to indicate that the encrypted file is a Kryptor file? Secondly, would you say a delay of 150 ms or 250 ms per file is appropriate?

samuel-lucas6 commented

2020-09-25 13:41:45 +00:00

(Migrated from github.com)

I've done some quick benchmarking of Konscious.Security.Cryptography.Argon2 vs libsodium's Argon2 and libsodium's implementation is miles faster with the same settings. So much so that I'm going to switch to it.

However, it does bother me that the salt is restricted to 16 bytes (even though that's obviously secure) and that there's no associated data or known secret. I guess the speed makes up for it though since the user can have more secure parameters with less delay.

I've done some quick benchmarking of Konscious.Security.Cryptography.Argon2 vs libsodium's Argon2 and libsodium's implementation is miles faster with the same settings. So much so that I'm going to switch to it. However, it does bother me that the salt is restricted to 16 bytes (even though that's obviously secure) and that there's no associated data or known secret. I guess the speed makes up for it though since the user can have more secure parameters with less delay.

lynn-stephenson commented

2020-09-25 16:34:49 +00:00

(Migrated from github.com)

I've done some quick benchmarking of Konscious.Security.Cryptography.Argon2 vs libsodium's Argon2 and libsodium's implementation is miles faster with the same settings. So much so that I'm going to switch to it.

However, it does bother me that the salt is restricted to 16 bytes (even though that's obviously secure) and that there's no associated data or known secret. I guess the speed makes up for it though since the user can have more secure parameters with less delay.

You can hash data prior to hashing it with Argon2, which is a good alternative. And a 16-byte salt is plenty, and should only be used for salt like purposes.

> I've done some quick benchmarking of Konscious.Security.Cryptography.Argon2 vs libsodium's Argon2 and libsodium's implementation is miles faster with the same settings. So much so that I'm going to switch to it. > > However, it does bother me that the salt is restricted to 16 bytes (even though that's obviously secure) and that there's no associated data or known secret. I guess the speed makes up for it though since the user can have more secure parameters with less delay. You can hash data prior to hashing it with Argon2, which is a good alternative. And a 16-byte salt is plenty, and should only be used for salt like purposes.

👍 1

samuel-lucas6 commented

2020-09-26 17:19:31 +00:00

(Migrated from github.com)

Ok I'm about half way through a complete code review. Should have version 2.0.0 Beta released sometime next week. I've updated the documentation on the website to reflect the changes. I should have implemented things this way originally, but better late than never.

The salt size has been dropped from 32 bytes to 16 bytes as per libsodium's requirement.
I'm now using BLAKE2 for hashing the password with associated data as the key.
BLAKE2 is now used for combining the password and keyfile instead of HMAC-SHA512.
Keyfiles are 64 bytes instead of 128 bytes due to this change, but that's more than enough.
BLAKE2 is also used as a MAC instead of HMAC-SHA512, again meaning the MAC key is now 64 bytes (512-bits) rather than 128 bytes (1024-bits).

In sum, everything is faster, the code has become more maintainable, and less DLLs are required with the executable.

Going to investigate the default Argon2 parameters currently used if the benchmark never runs (100 MiB & 3 iterations) to see what sort of delay that causes in my VM and adjust them accordingly. I think the 150 ms & 250 ms delays for the benchmark will probably be best, but I might see what 100 ms is like.

Ok I'm about half way through a complete code review. Should have version 2.0.0 Beta released sometime next week. I've updated the [documentation](https://kryptor.co.uk/Documentation.html) on the website to reflect the changes. I should have implemented things this way originally, but better late than never. - The salt size has been dropped from 32 bytes to 16 bytes as per libsodium's requirement. - I'm now using BLAKE2 for hashing the password with associated data as the key. - BLAKE2 is now used for combining the password and keyfile instead of HMAC-SHA512. - Keyfiles are 64 bytes instead of 128 bytes due to this change, but that's more than enough. - BLAKE2 is also used as a MAC instead of HMAC-SHA512, again meaning the MAC key is now 64 bytes (512-bits) rather than 128 bytes (1024-bits). In sum, everything is faster, the code has become more maintainable, and less DLLs are required with the executable. Going to investigate the default Argon2 parameters currently used if the benchmark never runs (100 MiB & 3 iterations) to see what sort of delay that causes in my VM and adjust them accordingly. I think the 150 ms & 250 ms delays for the benchmark will probably be best, but I might see what 100 ms is like.

❤️ 1

lynn-stephenson commented

2020-09-26 19:56:59 +00:00

(Migrated from github.com)

@Kryptor-Software It is looking really nice. So I was calcuating to see how long it would take to encrypt batches of files.

I have some projects that are in the 2000+ files. But we'll go with a 1000 to start.

250ms * 1,000 files ÷ 1,000ms = 250 seconds ≈ 4 minutes.

That's for key derivation. But that performance issue is huge:

This approach is great if you're doing single files, but it is definitely something to look into if you can encrypt folders of files under one key instead. Or create a file system like VeraCrypt (of course not with their cryptographic choices).

As of right now I'll wait till you've got version 2 out. Project looks awesome.

@Kryptor-Software It is looking really nice. So I was calcuating to see how long it would take to encrypt batches of files. I have some projects that are in the 2000+ files. But we'll go with a 1000 to start. 250ms * 1,000 files ÷ 1,000ms = 250 seconds ≈ 4 minutes. That's for key derivation. But that performance issue is huge: This approach is great if you're doing single files, but it is definitely something to look into if you can encrypt folders of files under one key instead. Or create a file system like VeraCrypt (of course not with their cryptographic choices). As of right now I'll wait till you've got version 2 out. Project looks awesome.

samuel-lucas6 commented

2020-09-27 10:31:24 +00:00

(Migrated from github.com)

@Kryptor-Software It is looking really nice. So I was calcuating to see how long it would take to encrypt batches of files.

I have some projects that are in the 2000+ files. But we'll go with a 1000 to start.

250ms * 1,000 files ÷ 1,000ms = 250 seconds ≈ 4 minutes.

That's for key derivation. But that performance issue is huge:

This approach is great if you're doing single files, but it is definitely something to look into if you can encrypt folders of files under one key instead. Or create a file system like VeraCrypt (of course not with their cryptographic choices).

As of right now I'll wait till you've got version 2 out. Project looks awesome.

Yeah I hear you, although for less files (e.g. 100 or less) I think the time it takes is acceptable. I'd like to know how long it takes Cryptomator to encrypt that many files because there's got to be some key wrapping delay. With AxCrypt and 1000 files you'd have a delay of 50 seconds for key wrapping. For a large number of files disk encryption or containers are a much better option.

Here are some quick file encryption benchmarks (XChaCha20, 250 ms delay for key derivation - 100 MiB & 3 iterations on my Windows VM):

Encryption: 30 MiB file - 1 second.
Decryption: 30 MiB file - 1.5 seconds.

Encryption: 10 x 30 MiB files - 4 seconds.
Decryption: 10 x 30 MiB files - 9 seconds.

Encryption: 70 files (*533 MiB) - 22 seconds.
Decryption: 70 files (533 MiB) - 35 seconds.

Using a mix of files 1 KiB - 77 MiB files - mostly small files.

Note that 'Anonymous Rename' and 'Memory Encryption' are enabled in settings, which both add some extra delay.

Decryption is noticeably slower, but there's nothing I can do about that with this arrangement. AxCrypt suffers from the same problem. However, these are much faster times than Kryptor version 1. For example, HMAC was taking 400-600 ms for a 35 MiB file, whereas BLAKE2 takes 50-80 ms.

Version 2 is going to stick with key derivation per file, but perhaps I can look into another way of doing it when encrypting folders in the future. That sort of change would make reading the salt and Argon2 parameters messy though as it would have to be different for files and folders. I'm trying to get version 2 out ASAP because I am going to be busy doing academic work soon and then development will slow down.

> @Kryptor-Software It is looking really nice. So I was calcuating to see how long it would take to encrypt batches of files. > > I have some projects that are in the 2000+ files. But we'll go with a 1000 to start. > > 250ms * 1,000 files ÷ 1,000ms = 250 seconds ≈ 4 minutes. > > That's for key derivation. But that performance issue is huge: > > This approach is great if you're doing single files, but it is definitely something to look into if you can encrypt folders of files under one key instead. Or create a file system like VeraCrypt (of course not with their cryptographic choices). > > As of right now I'll wait till you've got version 2 out. Project looks awesome. Yeah I hear you, although for less files (e.g. 100 or less) I think the time it takes is acceptable. I'd like to know how long it takes Cryptomator to encrypt that many files because there's got to be some key wrapping delay. With AxCrypt and 1000 files you'd have a delay of 50 seconds for key wrapping. For a large number of files disk encryption or containers are a much better option. Here are some quick file encryption benchmarks (XChaCha20, 250 ms delay for key derivation - 100 MiB & 3 iterations on my Windows VM): Encryption: 30 MiB file - 1 second. Decryption: 30 MiB file - 1.5 seconds. Encryption: 10 x 30 MiB files - 4 seconds. Decryption: 10 x 30 MiB files - 9 seconds. Encryption: 70 files (*533 MiB) - 22 seconds. Decryption: 70 files (533 MiB) - 35 seconds. * Using a mix of files 1 KiB - 77 MiB files - mostly small files. Note that 'Anonymous Rename' and 'Memory Encryption' are enabled in settings, which both add some extra delay. Decryption is noticeably slower, but there's nothing I can do about that with this arrangement. AxCrypt suffers from the same problem. However, these are much faster times than Kryptor version 1. For example, HMAC was taking 400-600 ms for a 35 MiB file, whereas BLAKE2 takes 50-80 ms. Version 2 is going to stick with key derivation per file, but perhaps I can look into another way of doing it when encrypting folders in the future. That sort of change would make reading the salt and Argon2 parameters messy though as it would have to be different for files and folders. I'm trying to get version 2 out ASAP because I am going to be busy doing academic work soon and then development will slow down.

👍 1

samuel-lucas6 commented

2020-09-29 14:29:45 +00:00

(Migrated from github.com)

Kryptor version 2.0.0 Beta has now been released! The changelog can be found in the GitHub release. Quite a lot of improvements have been made.

Kryptor version 2.0.0 Beta has now been released! The changelog can be found in the GitHub [release](https://github.com/Kryptor-Software/Kryptor/releases/tag/v2.0.0). Quite a lot of improvements have been made.

blacklight447 commented

2020-10-08 08:29:57 +00:00

(Migrated from github.com)

I vote for inclusion, but in the worth mentioning section for now, as the software is still new, and we should always be careful with new projects focused on encryption.

👍 2

samuel-lucas6 commented

2020-10-09 08:14:51 +00:00

(Migrated from github.com)

Based on the feedback I've been getting, I'm going to look into creating some Linux packages for the program - e.g. .deb, Flatpak perhaps. Never done anything like this before and am a bit busy at the moment, but I'll try and get that sorted at some point. Perhaps something similar can be done for macOS like KeePassXC does.

I also intend to try and apply for funding for an audit, but the chances of me being selected are very very slim. May as well try though, you never know. The deadline for the application is November, so I need to finish writing that. Won't hear back for a long time either.

Based on the feedback I've been getting, I'm going to look into creating some Linux packages for the program - e.g. .deb, Flatpak perhaps. Never done anything like this before and am a bit busy at the moment, but I'll try and get that sorted at some point. Perhaps something similar can be done for macOS like KeePassXC does. I also intend to try and apply for funding for an audit, but the chances of me being selected are very very slim. May as well try though, you never know. The deadline for the application is November, so I need to finish writing that. Won't hear back for a long time either.

👍 1

gary-host-laptop commented

2020-10-09 13:05:21 +00:00

(Migrated from github.com)

Based on the feedback I've been getting, I'm going to look into creating some Linux packages for the program - e.g. .deb, Flatpak perhaps. Never done anything like this before and am a bit busy at the moment, but I'll try and get that sorted at some point. Perhaps something similar can be done for macOS like KeePassXC does.

I also intend to try and apply for funding for an audit, but the chances of me being selected are very very slim. May as well try though, you never know. The deadline for the application is November, so I need to finish writing that. Won't hear back for a long time either.

I vote for it being released as a flatpak.

> Based on the feedback I've been getting, I'm going to look into creating some Linux packages for the program - e.g. .deb, Flatpak perhaps. Never done anything like this before and am a bit busy at the moment, but I'll try and get that sorted at some point. Perhaps something similar can be done for macOS like KeePassXC does. > > I also intend to try and apply for funding for an audit, but the chances of me being selected are very very slim. May as well try though, you never know. The deadline for the application is November, so I need to finish writing that. Won't hear back for a long time either. I vote for it being released as a flatpak.

samuel-lucas6 commented

2020-10-10 09:58:45 +00:00

(Migrated from github.com)

Based on the feedback I've been getting, I'm going to look into creating some Linux packages for the program - e.g. .deb, Flatpak perhaps. Never done anything like this before and am a bit busy at the moment, but I'll try and get that sorted at some point. Perhaps something similar can be done for macOS like KeePassXC does.
I also intend to try and apply for funding for an audit, but the chances of me being selected are very very slim. May as well try though, you never know. The deadline for the application is November, so I need to finish writing that. Won't hear back for a long time either.

I vote for it being released as a flatpak.

It looks like any sort of package is going to be harder to create than I first thought because of the Mono dependency. There doesn't seem to be any guidance on packaging Mono. I expect I'll have to look into how KeePass is packaged.

> > Based on the feedback I've been getting, I'm going to look into creating some Linux packages for the program - e.g. .deb, Flatpak perhaps. Never done anything like this before and am a bit busy at the moment, but I'll try and get that sorted at some point. Perhaps something similar can be done for macOS like KeePassXC does. > > I also intend to try and apply for funding for an audit, but the chances of me being selected are very very slim. May as well try though, you never know. The deadline for the application is November, so I need to finish writing that. Won't hear back for a long time either. > > I vote for it being released as a flatpak. It looks like any sort of package is going to be harder to create than I first thought because of the Mono dependency. There doesn't seem to be any guidance on packaging Mono. I expect I'll have to look into how KeePass is packaged.

😕 1

samuel-lucas6 commented

2020-10-11 09:07:55 +00:00

(Migrated from github.com)

Got some more bad news. Mono for Windows Forms and Wine are not supported on macOS Catalina because 32-bit application support has been removed in Catalina. This means you cannot currently run Kryptor on macOS 10.15.

However, I am now definitely going to work on a console version of Kryptor in .NET Core 3.1 that will be self-contained and portable. This will remove the Mono requirement on Linux and macOS. Then packaging the application should be easier as well.

Got some more bad news. Mono for Windows Forms and Wine are not supported on macOS Catalina because 32-bit application support has been removed in Catalina. This means you cannot currently run Kryptor on macOS 10.15. However, I am now definitely going to work on a console version of Kryptor in .NET Core 3.1 that will be self-contained and portable. This will remove the Mono requirement on Linux and macOS. Then packaging the application should be easier as well.

👍 1

samuel-lucas6 commented

2020-10-18 08:28:31 +00:00

(Migrated from github.com)

Another quick update: The CLI version is coming along nicely. Lots of the functionality is already working because I haven't had to modify the Kryptor code much, but I have to implement the settings. I also need to sort out a custom --help text and a few other minor things. Haven't tested it properly so far, but I expect I'll have it ready for some time in November.

🎉 1 🚀 1

sh-dv commented

2020-10-26 08:20:34 +00:00

(Migrated from github.com)

Hat.sh
Hat.sh uses PBKDF2 with 80,000 iterations, which is significantly better than AxCrypt but could still be increased. This iteration count is not adjustable unless you tweak the code. I would have set the iteration count to at least 100,000 but 80,000 isn't bad.

@samuel-lucas6

PBKDF2-SHA256 with 100k iterations does not even meet the standard for auth (<10kH/s/GPU). Standard for encryption is <1kH/s/GPU. Also most CPUs are 64bit which means SHA512 is a better choice for PBKDF2 until SHA-NI because more available. SHA512 takes about 25% longer because of the number of rounds is 80 vs 64. So PBKDF2-SHA512 with 80k iterations should take about the same time but will be twice as strong against GPUs. (Which hat.sh uses)

Cracking benchmarks (Using info from https://gist.github.com/epixoip/47098d25f171ec1808b519615be1b90d )

PBKDF2-SHA256 100k: 21.26 kH/s

PBKDF2-SHA512 80k: 9.995 kH/s

Thanks. Love your project.
stay tuned for v2.0 beta soon.

> **Hat.sh** > [Hat.sh](https://hat.sh/about.html) uses PBKDF2 with 80,000 iterations, which is significantly better than AxCrypt but could still be increased. This iteration count is not adjustable unless you tweak the code. I would have set the iteration count to at least 100,000 but 80,000 isn't bad. > @samuel-lucas6 PBKDF2-SHA256 with 100k iterations does not even meet the standard for auth (<10kH/s/GPU). Standard for encryption is <1kH/s/GPU. Also most CPUs are 64bit which means SHA512 is a better choice for PBKDF2 until SHA-NI because more available. SHA512 takes about 25% longer because of the number of rounds is 80 vs 64. So PBKDF2-SHA512 with 80k iterations should take about the same time but will be **twice** as strong against GPUs. (Which hat.sh uses) Cracking benchmarks (Using info from https://gist.github.com/epixoip/47098d25f171ec1808b519615be1b90d ) PBKDF2-SHA256 100k: 21.26 kH/s PBKDF2-SHA512 80k: 9.995 kH/s Thanks. Love your project. stay tuned for v2.0 beta soon.

👍 2 🎉 1

samuel-lucas6 commented

2020-10-26 08:54:28 +00:00

(Migrated from github.com)

Hat.sh
Hat.sh uses PBKDF2 with 80,000 iterations, which is significantly better than AxCrypt but could still be increased. This iteration count is not adjustable unless you tweak the code. I would have set the iteration count to at least 100,000 but 80,000 isn't bad.

@samuel-lucas6

PBKDF2-SHA256 with 100k iterations does not even meet the standard for auth (<10kH/s/GPU). Standard for encryption is <1kH/s/GPU. Also most CPUs are 64bit which means SHA512 is a better choice for PBKDF2 until SHA-NI because more available. SHA512 takes about 25% longer because of the number of rounds is 80 vs 64. So PBKDF2-SHA512 with 80k iterations should take about the same time but will be twice as strong against GPUs. (Which hat.sh uses)

Cracking benchmarks (Using info from https://gist.github.com/epixoip/47098d25f171ec1808b519615be1b90d )

PBKDF2-SHA256 100k: 21.26 kH/s

PBKDF2-SHA512 80k: 9.995 kH/s

Thanks. Love your project.
stay tuned for v2.0 beta soon.

Thanks sh-dv. I really like your project as well. I now understand why you chose 80,000 iterations. I wasn't aware it was PBKDF2-SHA512 because it just says PBKDF2 on the website About page.

> > **Hat.sh** > > [Hat.sh](https://hat.sh/about.html) uses PBKDF2 with 80,000 iterations, which is significantly better than AxCrypt but could still be increased. This iteration count is not adjustable unless you tweak the code. I would have set the iteration count to at least 100,000 but 80,000 isn't bad. > > @samuel-lucas6 > > PBKDF2-SHA256 with 100k iterations does not even meet the standard for auth (<10kH/s/GPU). Standard for encryption is <1kH/s/GPU. Also most CPUs are 64bit which means SHA512 is a better choice for PBKDF2 until SHA-NI because more available. SHA512 takes about 25% longer because of the number of rounds is 80 vs 64. So PBKDF2-SHA512 with 80k iterations should take about the same time but will be **twice** as strong against GPUs. (Which hat.sh uses) > > Cracking benchmarks (Using info from https://gist.github.com/epixoip/47098d25f171ec1808b519615be1b90d ) > > PBKDF2-SHA256 100k: 21.26 kH/s > > PBKDF2-SHA512 80k: 9.995 kH/s > > Thanks. Love your project. > stay tuned for v2.0 beta soon. Thanks sh-dv. I really like your project as well. I now understand why you chose 80,000 iterations. I wasn't aware it was PBKDF2-SHA512 because it just says PBKDF2 on the website About page.

👍 1

sh-dv commented

2020-10-26 09:02:46 +00:00

(Migrated from github.com)

it is ok, i'm gonna add that in the about page. thanks.

done : 7b0a3a268f

it is ok, i'm gonna add that in the about page. thanks. done : https://github.com/sh-dv/hat.sh/commit/7b0a3a268f1f6d7ba7b08c3c23a7c16d8432208f

This repo is archived. You cannot comment on issues.