Giter VIP home page Giter VIP logo

Comments (8)

samuel-lucas6 avatar samuel-lucas6 commented on August 21, 2024

Thank you for the feedback. I'm happy to try and explain all of those points.

  1. The directory apparently wasn't found, meaning the directory name couldn't be changed. I don't think I can really make that error any clearer.
  2. That must be the file that was created by Kryptor and used to store the original directory name since you specified --obfuscate. That text file is overwritten with encrypted data because otherwise the directory name would be left stored in plaintext. I can't hide the message saying that file was encrypted since there's no way of finding out which files are which.
  3. The folder was not renamed to Test - Copy, the directory was backed up (as mentioned in the Test: This directory is being backed up... message) because you didn't specify --overwrite as an option. The files in the original directory were all overwritten with encrypted data, but the original files were copied to a backup directory beforehand. I should probably display the name of the backup directory in the terminal, but I think there may have been a reason why I didn't do that. I can look into that.
  4. Kryptor uses chunked encryption, meaning files are encrypted in 16 KiB chunks, even if they are smaller than 16 KiB. This hides the exact length of the encrypted data. I expect those other programs don't do this.

I recommend using -o|--overwrite when encrypting files/directories unless you want to keep an unencrypted backup of the files.

from kryptor.

sergeevabc avatar sergeevabc commented on August 21, 2024

I'm happy to… explain all of those points.

Thank you, @samuel-lucas6. However, let me quote Moxie Marlinspike, a man behind Signal messenger: “The GnuPG man page is over 16k words long; for comparison, the novel Fahrenheit 451 is only 40k words.” Bottom line is that expectations should be anticipated as much as possible, not explained afterwards as verbose as possible.

If the app is not able to distinguish between files and folders whose names begin with a dot (while competitors are able) and displays an error message about, then why it continues to work and even displays a success message? Essentially, it is a sabotage of user’s command which gives a false sense of security. Stop the job at once with an explanation like “fix the input and try again”.

Confusion grows even more when the app displays source-destination pairs with files like ripyn4kjnqxz2arn24rhl0.txt in the source column while no such files exist in the source. Essentially, it is perceived as a lie, regardless of what internal procedures were involved and affected the output. Be honest: real-source.ext -> obfuscated-destination.kryptor.

Backing up a source folder is neither expected nor necessary. Just let it be until user asks to remove it by a related switch.

As for 16 KiB chunks to hide the original length, it seems to be an excessive measure for the most threat scenarios, thus consider this approach to be a paranoid option (maybe even coupled with B-trees cutting of originals), not a default setting. Size fluctuations are enough to hide the original length (like gpg --symmetric, 7z and mentioned FUSE solutions do), whereas a significant size increase is not expected and not easy to predict when lots of small files are processed (e.g. *.md, *.eml).

Icing on the cake is that the app tries hard to be ultra-secure, which leads to uncomfortable delays. It freezes for ~10 seconds on my PC and even longer on a laptop between the password input and the actual encryption. By contrast, Keepass 1 MiB database (ChaCha20+Argon2id t4×m128×p2) is synced with a cloud and decrypted several times faster.

from kryptor.

samuel-lucas6 avatar samuel-lucas6 commented on August 21, 2024

@sergeevabc Let me clarify a few more things.

It freezes for ~10 seconds on my PC and even longer on a laptop between the password input and the actual encryption.

I can assure you that Kryptor is not freezing.

  • If you're still talking about directory encryption without -o|--overwrite, then it will copy all of the files in that directory to a new directory. That will take some time. I presume this is what you're referring to.
  • If you use a private key, then it takes 1 second to perform key derivation to decrypt the private key.
  • If you use a password for directory encryption, it takes 1 second per specified directory for key derivation.
  • If you use a password and specify files individually (rather than specifying a folder), then it will take 1 second per file for key derivation.

By contrast, Keepass 1 MiB database (ChaCha20+Argon2id t4×m128×p2) is synced with a cloud and decrypted several times faster.

That is to be expected. KeePass is always performing key derivation once and for significantly less time than Kryptor with those settings (Kryptor uses 12 iterations and 256 MiB). KeePass is also only handling one file, it's not overwriting any files, it's not copying any files, etc. The actual encryption/decryption in Kryptor is relatively fast, but it's difficult to measure due to the key derivation delay.

As for 16 KiB chunks to hide the original length, it seems to be an excessive measure for the most threat scenarios, thus consider this approach to be a paranoid option (maybe even coupled with B-trees cutting of originals), not a default setting.

16 KiB was chosen because it's a sensible size for chunked encryption. You make a fair point about small files, but 16 KiB doesn't result in much overhead for larger files. The main reason why Kryptor always encrypts in 16 KiB chunks is for simplicity and consistency, but hiding the original length is an additional benefit. Perhaps I shouldn't have done it this way, but most files are larger than 16 KiB.

I also forgot to mention in my previous reply that because the encryption is chunked, that means each chunk has a 32 byte authentication tag. This also adds to the file size, but this is unavoidable when doing chunked encryption.

Backing up a source folder is neither expected nor necessary. Just let it be until user asks to remove it by a related switch.

I'm afraid I don't understand what you mean. If you don't specify -o|--overwrite, then it signals to the program that you don't want to overwrite your files. When it comes to directories, it would be a nightmare to organise your files if the encrypted files were in the same directory as the unencrypted files. I also wanted to ensure that the files storing directory names were overwritten with encrypted data, regardless of whether -o|--overwrite was specified.

Confusion grows even more when the app displays source-destination pairs with files like ripyn4kjnqxz2arn24rhl0.txt in the source column while no such files exist in the source. Essentially, it is perceived as a lie, regardless of what internal procedures were involved and affected the output. Be honest: real-source.ext -> obfuscated-destination.kryptor.

I understand and agree with your point, but as I said in my previous reply, at that place in the code (where that message is displayed), it's not really possible to identify which file is which and not display that message. It could probably be done, but it wouldn't be pretty.

If the app is not able to distinguish between files and folders whose names begin with a dot (while competitors are able) and displays an error message about, then why it continues to work and even displays a success message? Essentially, it is a sabotage of user’s command which gives a false sense of security. Stop the job at once with an explanation like “fix the input and try again”.

I would need more details to establish what happened as there are all sorts of reasons for IO errors. However, it didn't sabotage the user's command, the directory was unable to be renamed, but the files in that folder were still able to be encrypted. If encryption had stopped after that error, then only some of the entire directory would be encrypted, which would completely mess up the key derivation. That would be especially troublesome for the user if -o|--overwrite had been specified.

Bottom line is that expectations should be anticipated as much as possible, not explained afterwards as verbose as possible.

If only it was that simple. It's a nightmare deciding how to handle files - e.g. whether to overwrite everything, make copies, etc. Error handling is also not fun. You can't keep everyone happy, and you have to make some compromises.

Previous versions of Kryptor used to overwrite input files by default, but a --no-overwrite or --do-not-overwrite option doesn't sound as good as --overwrite, and the public key encryption is one-way, meaning users would likely lose access to their files by accident.

from kryptor.

samuel-lucas6 avatar samuel-lucas6 commented on August 21, 2024

.notable - Error: DirectoryNotFoundException - Unable to obfuscate directory name.

I'll try to replicate this error to check whether it's a code problem. This issue has also made me notice a different problem that will be fixed in the next release.

from kryptor.

sergeevabc avatar sergeevabc commented on August 21, 2024

If you use a password and specify files individually… then it will take 1 second per file for key derivation.

$ mkrandom 2k 2048.txt
$ procprofile kryptor -e -p 2048.txt

Enter a password (leave empty for a random passphrase): 1
Retype password: 1
2048.txt => 2048.txt.kryptor                                          
Successfully encrypted: 1/1                                       

Clock Time : 6.401s                               

Typing password as simple as digit 1 took me less than 1 second, so key derivation took ~5 seconds, not 1. Is this delay justified? In my opinion, no. You can instantly encrypt the same file with gpg or 7zip using 4-5 words passphrase and sleep well for decades. Using slightly more modern algos with slightly better protection against slightly more serious attacks is a selling point that plays on the fears, but 9/10 of successful cracking is about physical pressure, not GPU-accelerated brute-forcing.

Backing up a source folder is neither expected nor necessary. Just let it be until user asks to remove it by a related switch.

I'm afraid I don't understand what you mean.

After kryptor -e -p -f C:\Test is finished, there are C:\55al011mr1ddmw3skqmhsz and C:\Test - Copy, whereas it is expected to get C:\55al011mr1ddmw3skqmhsz and still have C:\Test without that extra backup step. Just like after a single file encryption is finished, we get 2048.txt.kryptor, whereas source 2048.txt is left intact, not renamed, not removed, not backed up (hooray!).

Be honest: real-source.ext -> obfuscated-destination.kryptor.

I … agree with your point, but … it's not really possible to identify which file is which

Then give up on fake pairs and display only files counter/percentages as a process indicator. Less verbose, but more credible.

Oh, and by the way, Kryptor sets read-only flag on encrypted files without user’s consent. Aggrrhhh.

from kryptor.

samuel-lucas6 avatar samuel-lucas6 commented on August 21, 2024

Typing password as simple as digit 1 took me less than 1 second, so key derivation took ~5 seconds, not 1.

You're including the time it takes to type the password twice, the time for key derivation, and the time it takes to encrypt the file in that total clock time. Is 2048.txt 2 KiB in size? What are the specs of your machine? It should take between ~1-1.2 seconds on modern hardware for key derivation based on my testing using my machine and a VM.

With a 34.1 MiB JPG file that I use for testing, the key derivation and encryption time is ~1.5 seconds on my machine, which suggests roughly 0.5 seconds for the encryption. With a 781 MiB ZIP file, the key derivation and encryption time is ~3 seconds, which suggests roughly 2 seconds for the encryption.

I would not call either of those times slow, and the program is doing a lot more than just encryption in that time - e.g. there's a bunch of validation as well.

The key derivation uses a large delay because I wanted to be consistent throughout the program - e.g. to use the same key derivation delay for folders and individual files so that individual files in the folder can be decrypted outside of the folder. When deriving a single key for an entire directory and all subdirectories, you want a relatively large delay. When protecting a private key, you want a pretty big delay. Using different delays for different purposes complicates things.

9/10 of successful cracking is about physical pressure, not GPU-accelerated brute-forcing.

I disagree. Yes, physical pressure plays a role when it comes to law enforcement. However, if someone hacked into your cloud storage and downloaded one of your encrypted files, then you would want to ensure that they can't decrypt it. When using a password, that really comes down the password strength, but a decent key derivation delay is good practice.

After kryptor -e -p -f C:\Test is finished, there are C:\55al011mr1ddmw3skqmhsz and C:\Test - Copy, whereas it is expected to get C:\55al011mr1ddmw3skqmhsz and still have C:\Test without that extra backup step.

Right, now I get you. The reason that doesn't happen is because when the directory is being copied, C:\Test already exists, meaning the backup directory cannot also be C:\Test. To remove - Copy isn't as easy as you'd think because it's not necessarily going to have that name. The name of the backup folder depends on whether there's already a folder called C:\Test - Copy. If there is, the backup directory will be renamed to C:\Test - Copy (2). You'd have to store the backup directory name and pass that variable around in the code, which would be messy.

Then give up on fake pairs and display only files counter/percentages as a process indicator. Less verbose, but more credible.

The file names are being displayed so that the user can see what has been encrypted to what, which may be useful when they use the --obfuscate option. You say 'more credible', but the directory name files are technically in the folder, so saying those files have been encrypted is not lying. However, I understand why it's confusing.

Oh, and by the way, Kryptor sets read-only flag on encrypted files without user’s consent. Aggrrhhh.

'Without user's consent' is required for lots of things when performing file handling. It would be a terrible idea to ask the user after encrypting each file whether they wanted it to be read-only, and having a --readonly-only option would complicate the program.

Why is it problematic that encrypted files are read-only? You shouldn't be interacting with them anyway. They're made read-only in an attempt to prevent accidental modification, which would result in not being able to decrypt files. By contrast, decrypted files are not read-only.

from kryptor.

sergeevabc avatar sergeevabc commented on August 21, 2024

You're including the time it takes to type the password twice,

No. I really type(-d) the sequence 1+ENTER+1+ENTER in a second or less.

How big is 2048.txt?

mkrandom with 2k switch generated random 2048 bytes, hence 2048.txt.

What are the specs of your machine?

Two cores × 2.4 GHz overclocked to 3.3 GHZ, 4 GB RAM, Windows 7. Average Joe’s machine who lives outside the golden billion.
E.g. it’s enough to mount widely used Veracrypt (successor of Truecrypt) containers (SHA2, t500000) with no annoying delay.

Physical pressure plays a role when it comes to law enforcement.
If someone hacked into your cloud storage and downloaded one of your encrypted files…

Pressure cases I witnessed include law enforcement, spying employers, debt collectors, and jealous (ex-)lovers to name a few. None of them used a computing power to gain access. Because breaking a secret owner is easier and cheaper than renting a farm with John the Ripper rigs to break a secret. Whereas rumors and news of successfully cracked files (properly encrypted with 7z, gpg, and other aforementioned tools) are scarce. Hence 9/10 stats.

When protecting a private key, you want a pretty big delay…

“You want a pretty big delay”, “you want a backup”, “you want a read-only flag on encrypted files”. Actually, it is what you want to reduce anxiety about threats hidden in the shadow of unknown future (viz. imaginary dragons), the rest are psycho-projections and forcing habits. But here comes the Other, invalidates sluggish’n’intrusive design and calls to face the challenge of today which is to make crypto widespread (so we are not marked as suspicious for using crypto), hence balanced in terms of usability.

Nevertheless, I am grateful for the efforts in this direction.

from kryptor.

samuel-lucas6 avatar samuel-lucas6 commented on August 21, 2024

mkrandom with 2k switch generated random 2048 bytes, hence 2048.txt.

Sorry, I did realise that after the fact and edited my reply.

E.g. it’s enough to mount widely used Veracrypt (successor of Truecrypt) containers (SHA2, t500000) with no annoying delay.

There will still be several seconds of key derivation delay for VeraCrypt. In fact, it should be more delay than Kryptor if you're comparing decrypting one directory against decrypting a VeraCrypt container. I can't remember how long PBKDF2 takes with a high iteration count, but I think 100,000 is probably at least a second and VeraCrypt uses something in the 200,000 range by default.

Whereas rumors and news of successfully cracked files (properly encrypted with 7z, gpg, and other aforementioned tools) are scarce.

That doesn't mean it won't happen. It's not newsworthy if someone is using a weak password. Lots of people's accounts are breached, but you won't hear about it on the news unless lots of accounts have been breached in one large scale attack.

“You want a pretty big delay”, “you want a backup”, “you want a read-only flag on encrypted files”. Actually, it is what you want to reduce anxiety about threats hidden in the shadow of unknown future (viz. imaginary dragons), the rest are psycho-projections and forcing habits.

I'm trying to follow recommended practices and make logical decisions based on predictions. I know it's not perfect, and I accept that I may have gotten a few things wrong since I have barely received any feedback.

I doubt most people mind having read-only encrypted files, but I completely understand your criticism of the delay and directory backup. However, I'm afraid I don't intend to make any major changes without more feedback expressing the same opinion. A change to the key derivation delay would be a significant breaking change. Most of the other things discussed in this issue can't be changed either as I have already explained, but I will look into encrypting the backup directory instead of the original directory.

Thank you for your feedback.

from kryptor.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.