Add Features

[HACKERALERT]

This is mostly a reminder and workspace for me for the two features discussed in #153:

1. Recursively: Add the ability in the GUI to encrypt files recursively. For example, instead of encrypting an entire folder of movies and having to decrypt all the movies and extract them every time to watch just one movie, this option would allow each movie to be encrypted and decrypted separately.
2. Deniability: Add a plausible deniability option that re-encrypts the output volume with a key based off of the password, but without any header info. I'm planning to add this as an advanced feature that is off by default because it would approximately double the encryption time.

Keep in mind that while I do hope to implement these features, I cannot guarantee anything. It may take a year to implement, or I may not implement them at all. Use Picocrypt for what it is, not what it may become :)

PS: If anyone is willing to help me test these two features in the future, please leave a comment with your OS so that I know what to compile for. Thanks!

[HACKERALERT]

@AsuxAX @Minibus93 I've just added the plausible deniability feature and will likely be able to add the recursive option as well by tomorrow afternoon. Are any of you willing to help me test the two features? If so, let me know your OS so that I can save some time and only compile what I need to. If all goes well, these two features should be present in the upcoming v1.32 which I plan to release this Friday.

[Minibus93]

Sure, I'm on w10 (22H2 if I remember correctly)

[Asudox]

Same as Minibus93.

[BigPanda97]

Btw: The AppImage version for Linux does not work on RaspPi (aarch64). Would it be possible to make the AppImage files compatible with it in the future?

[HACKERALERT]

@BigPanda97 The AppImage is built for amd64, so it won't work on arm64. I don't think AppImages support cross-architecture, so the only way to support arm64 is to build two separate AppImages, which is annoying because I would need to spin up QEMU to compile for arm64. Does building from source work on your RasPi?

[HACKERALERT]

@Minibus93 @AsuxAX Awesome, I won't have to spin up a VM then :)

Here it is. Both features have been added. The recursive feature should be easy to test, I'll leave that to you to figure out. The plausible deniability feature is a little harder to test, by design. One way is to encrypt a small file without deniability and open it in notepad to see "v1.32" at the beginning of the file, which is the default unencrypted header, and then encrypting again but with deniability and seeing that the "v1.32" disappears when you open it in notepad, since the volume is now a random stream of bytes. Not sure if that made sense, but I'll leave it to you! There are a lot of different combinations and cases when you add on the other advanced features, so there could be some bugs. I've tried to go through every possible case and handle it, though, so it should be pretty stable. Let me know what you think!

Picocrypt.zip

[Asudox]

@Minibus93 @AsuxAX Awesome, I won't have to spin up a VM then :)

Here it is. Both features have been added. The recursive feature should be easy to test, I'll leave that to you to figure out. The plausible deniability feature is a little harder to test, by design. One way is to encrypt a small file without deniability and open it in notepad to see "v1.32" at the beginning of the file, which is the default unencrypted header, and then encrypting again but with deniability and seeing that the "v1.32" disappears when you open it in notepad, since the volume is now a random stream of bytes. Not sure if that made sense, but I'll leave it to you! There are a lot of different combinations and cases when you add on the other advanced features, so there could be some bugs. I've tried to go through every possible case and handle it, though, so it should be pretty stable. Let me know what you think!

Picocrypt.zip

How do you actually recursively decrypt files? I am sure the program does not check the file extensions when you drop a folder.

[HACKERALERT]

Is it necessary? I've already thought about this and explicitly disabled recursive decrypting because there are many things that can go wrong. For example, if the volumes have different passwords, how do I handle that without adding a lot of complexity? What about volumes using different keyfiles? How do I even show the option to recursive decrypt if dropping in folders by default is seen as encryption? If you need to bulk decrypt, maybe you shouldn't bulk encrypt in the first place :). Keeping the GUI clean is important and I've already added two new features. I'd rather these uncommon cases be handled by the CLI than to burden the GUI with something that most people won't need. I'm open to suggestions, of course. No bugs so far, correct?

On Wed, Apr 26, 2023, 1:32 p.m. AsuxAX @.***> wrote:

@Minibus93 https://github.com/Minibus93 @AsuxAX https://github.com/AsuxAX Awesome, I won't have to spin up a VM then :)

Here it is. Both features have been added. The recursive feature should be easy to test, I'll leave that to you to figure out. The plausible deniability feature is a little harder to test, by design. One way is to encrypt a small file without deniability and open it in notepad to see "v1.32" at the beginning of the file, which is the default unencrypted header, and then encrypting again but with deniability and seeing that the "v1.32" disappears when you open it in notepad, since the volume is now a random stream of bytes. Not sure if that made sense, but I'll leave it to you! There are a lot of different combinations and cases when you add on the other advanced features, so there could be some bugs. I've tried to go through every possible case and handle it, though, so it should be pretty stable. Let me know what you think!

Picocrypt.zip https://github.com/HACKERALERT/Picocrypt/files/11328831/Picocrypt.zip

How do you actually recursively decrypt files? I am sure the program does not check the file extensions when you drop a folder.

— Reply to this email directly, view it on GitHub https://github.com/HACKERALERT/Picocrypt/issues/154#issuecomment-1523803013, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALUMDTEFKU2O52PB3PDNKJLXDFL2JANCNFSM6AAAAAAXJXZHYI . You are receiving this because you authored the thread.Message ID: @.***>

[Asudox]

Is it necessary? I've already thought about this and explicitly disabled recursive decrypting because there are many things that can go wrong. For example, if the volumes have different passwords, how do I handle that without adding a lot of complexity? What about volumes using different keyfiles? How do I even show the option to recursive decrypt if dropping in folders by default is seen as encryption? If you need to bulk decrypt, maybe you shouldn't bulk encrypt in the first place :). Keeping the GUI clean is important and I've already added two new features. I'd rather these uncommon cases be handled by the CLI than to burden the GUI with something that most people won't need. I'm open to suggestions, of course. No bugs so far, correct? … On Wed, Apr 26, 2023, 1:32 p.m. AsuxAX @.> wrote: @Minibus93 https://github.com/Minibus93 @AsuxAX https://github.com/AsuxAX Awesome, I won't have to spin up a VM then :) Here it is. Both features have been added. The recursive feature should be easy to test, I'll leave that to you to figure out. The plausible deniability feature is a little harder to test, by design. One way is to encrypt a small file without deniability and open it in notepad to see "v1.32" at the beginning of the file, which is the default unencrypted header, and then encrypting again but with deniability and seeing that the "v1.32" disappears when you open it in notepad, since the volume is now a random stream of bytes. Not sure if that made sense, but I'll leave it to you! There are a lot of different combinations and cases when you add on the other advanced features, so there could be some bugs. I've tried to go through every possible case and handle it, though, so it should be pretty stable. Let me know what you think! Picocrypt.zip https://github.com/HACKERALERT/Picocrypt/files/11328831/Picocrypt.zip How do you actually recursively decrypt files? I am sure the program does not check the file extensions when you drop a folder. — Reply to this email directly, view it on GitHub <#154 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALUMDTEFKU2O52PB3PDNKJLXDFL2JANCNFSM6AAAAAAXJXZHYI . You are receiving this because you authored the thread.Message ID: @.>

But then, what is the purpose of recursively encrypting a folder if you can't undo the encryption by recursively decrypting? I don't see a reason to recursively encrypt a folder just to decrypt the recursively encrypted folder's files individually again. It is your choice in the end though. I guess you could like add the hash of the password the file is encrypted with to the file's unencrypted header part you've mentioned before (the part where the version is stated) so that the program knows which ones to decrypt. What do you think, @Minibus93?

As far as I used the new compiled version, no bugs so far that I noticed.

[HACKERALERT]

Yeah it's a weird situation. The way I envisioned the feature would be used is on movies, for example, where instead of encrypting the entire series, it would encrypt each episode individually so you can watch them individually. Can you name some cases where you would want to encrypt recursively and decrypt recursively, instead of just encrypting them with the default option which zips them together? That would give me more context to think of a solution.

The other thing is that if you drop a folder with both volumes and unencrypted files in it, what is supposed to happen? I can think of three possibilities:

• Encrypt the files, ignore the volumes
• Decrypt the volumes, ignore the files
• Encrypt the files, decrypt the volumes

Keep in mind that Picocrypt is supposed to be simple, so supporting all three options would be unrealistic. And if you drop this folder into the program, what is the main button supposed to say? Encrypt or Decrypt? There's a lot to consider and I'm honestly not too sure either. Maybe we can wait for @Minibus93's suggestions (no pressure!) to have another perspective.

[Asudox]

Yeah it's a weird situation. The way I envisioned the feature would be used is on movies, for example, where instead of encrypting the entire series, it would encrypt each episode individually so you can watch them individually. Can you name some cases where you would want to encrypt recursively and decrypt recursively, instead of just encrypting them with the default option which zips them together? That would give me more context to think of a solution.

The other thing is that if you drop a folder with both volumes and unencrypted files in it, what is supposed to happen? I can think of three possibilities:

• Encrypt the files, ignore the volumes
• Decrypt the volumes, ignore the files
• Encrypt the files, decrypt the volumes

Keep in mind that Picocrypt is supposed to be simple, so supporting all three options would be unrealistic. And if you drop this folder into the program, what is the main button supposed to say? Encrypt or Decrypt? There's a lot to consider and I'm honestly not too sure either. Maybe we can wait for @Minibus93's suggestions (no pressure!) to have another perspective.

As I said in my first issue, one use case where I would use recursive encryption is when I would want to encrypt USB devices. That would be one use case for me. However, now that I think about it, it sure does add complexity. I didn't think about the things you mentioned. I honestly don't know at this point how you could achieve that without adding complexity. I will be waiting for Minibus93 to say something about it. To keep the program simple, you might also just want to remove the recursive encryption option completely in the next release. As it seems, ensuring that it works well can only be achieved through complexity. You denied the requests to add this feature because of this in the past, right?

[BigPanda97]

As I said in my first issue, one use case where I would use recursive encryption is when I would want to encrypt USB devices.

But that is NOT a secure use case for this tool anyways. As the author also said in the documents, the file-shredding feature has been removed because it is insecure on USB/Flash/SSD devices. So by encrypting files on your USB device, the original plaintext files will always remain recoverable on the drive. For mobile devices like USB drives, a full-disk-encryption is ALWAYS necessary.

[Minibus93]

@HACKERALERT @AsuxAX Sorry to keeping you waiting gentlemen.

So, I took some time testing Picocrypt new features (and did some "just checking tests with the already existant features to see if there were side effects/bugs)

Here are my views after the testing:

1) as far as I can tell, there should be no bugs added, and if any, they are at least non evident.

2) deniability works just fine, cool!

Now, the recursive encryption...this has been giving me way more dilemmas than I exptected.

Let's start saying that recursive encryption works, in the sense that behaves in the exact way @HACKERALERT was expecting when implementing it.

But, the point here is way more complex. As @AsuxAX, I too find the current implementation of recursive encryption useful, but inconvenient (and for this I'm verry sorry for suggesting @HACKERALERT to work on it. This "loop hole" was something I had to predict before suggesting the feature, I'm really sorry for this.)

Both points applies here: @AsuxAX is correct saying that recursive encryption without recursive decryption sure is inconvenient. @HACKERALERT that implementing it with recursive decryption is something very hard because there's just SO MUCH that could go wrong.

Now, the question is: what to do? Let's start by listing all the possible choices: (this is, of course, my POV. "Your software, your rules" statement always applies)

1) Just release new Picocrypt version adding plausible deniability (which behaved just fine in my testing), however I feel this would break the symmetry in the GUI options that @HACKERALERT was refering to earlier. 2) Release new Picocrypt version with both the new features as work as intended when writing them (altough I find it hard to see a user using the recursive encryption without the recursive decryption. Again, I blame me so much for not thinking of this earlier) 3) Put this on hold (long term) until a way to have to recursive encryption with recursive decryption is found (I really can't think of any though, even by putting some limit rules for recursive decryption, it would be hard to have these rules clear to everyone using Picocrypt without clogging the GUI)

I feel that some could suggest of only adding this as CLI feature, however I'm really against such ideas (for any features, really) because I think that we all can agree that Picocrypt strong point is the GUI and starting to add exclusive features to CLI-only would weaken Picocrypt strong point.

In case you're wondering what I would do, I'd go for the third one and put this on long term thinking.

[HACKERALERT]

@AsuxAX Yeah I've skipped past this feature in the past because of the potential complexities. It's an important feature that has to be implemented at some point, though, so I might as well figure it out now while I can bundle it with deniability and release them together. So @Minibus93, you're not at fault for anything, I just happen to be very detailed and thorough with designing Picocrypt so I will naturally catch a lot of potential issues that others may not see.

Thank you for both of your points. I agree with @AsuxAX that if I add recursive encryption, recursive decryption should be added as well. I can imagine the pain of encrypting hundreds of files recursively only to have to decrypt them manually. While the CLI could do that, the GUI is the main priority and everything that the GUI can create should be decryptable in the GUI. Besides, the CLI doesn't support keyfiles or advanced features (at the moment). I also do realize the potential complexities and stability issues with adding recursive decryption. A poorly implemented feature is worse than no feature at all, in my opinion. I've thought about this for a while and I think I've come up with a good compromise. In fact, I think this solution is good enough that it isn't even a compromise:

When a user drops files and folders and toggles the "Recursive" option, the start button shows "Work" instead of "Encrypt" or "Decrypt". This implies that the operation neither only encrypts nor only decrypts files. Then when the "Work" button is pressed, all unencrypted files will be encrypted, and all volumes that can successfully decrypted with the password and/or keyfiles provided will be decrypted, while the others will be ignored. This is basically the third possibility I mentioned, and I think it will work because a hash of the encryption key is already stored in every volume's header, so if a decryption is unsuccessful, Picocrypt will know to delete any temporary files and skip it. Also, there's not much code or complexity to add with this system. With the current code, I can just change a few lines and everything will work as described.

So with this system, if you want to encrypt a bunch of files, just drag them in and press "Work". All files will be encrypted. To decrypt them, put all of the volumes in a folder and press "Work". Assuming that all the volumes use the same password and/or keyfiles, they will be decrypted. Ones that use different passwords and/or keyfiles will be ignored. And for the crazy people who want to both encrypt and decrypt at the same time, that will work as well.

This system should give the user enough flexibility to encrypt and decrypt however they want, without adding too much code or bugs. As a cherry on top, all existing features should all integrate smoothly with this new system and work correctly. Let me know what you think @AsuxAX @Minibus93.

[HACKERALERT]

Here's an updated preview. If this is good, I will try to release v1.32 by the end of the weekend. Picocrypt.zip

[Asudox]

Here's an updated preview. If this is good, I will try to release v1.32 by the end of the weekend. Picocrypt.zip

Looks good, no bugs I've encountered so far. The recursive decrypt feature works well for my use case.

[Minibus93]

@HACKERALERT

So, I've tested the new preview .exe and no bugs were found so far. I tested the two new features purposedly trying to screw things up by mixing with the already implemented features and no issues were found.

So bugs wise it seems perfect and clean and I'm also a fan of the way you implemented the recursive decryption. So I'd say it's a success!

If I really have to note something, I think that on the button the verb "Process" fits better than "Work" as "Process" puts more focus on the fact that a series of steps will be executed instead of just encryption, but this is just a minor language thing, probably just nitpicking so if you like "Work" better, that's totally fine!

[HACKERALERT]

Awesome, thank you both for your help in designing and testing these features. I will likely be able to release them in v1.32 by the end of this weekend.

@Minibus93 Thanks for suggesting "Process", that's a lot better indeed. I couldn't think of anything better so I just used "Work", which is the name of the function that does all of the work, but I will change it to "Process".

I will close this issue now as both features are implemented and work without bugs. Feel free to reopen at anytime, of course.