Picocrypt addition

[ThisIsNotANamepng]

I think the project Picocrypt (https://github.com/HACKERALERT/Picocrypt) should be added to the website as a suggestion for file encryption. It's main function is to encrypt files with ChaCha20, and has other options such as encoding with Reed-Solomon, compressing files, encrypting with key files and a password generator. It's written entirely in Go, and has translations for Turkish, German, Brazilian Portuguese, Lithuanian, and Spanish. In addition to encrypting files, it also has a checksum generator and secure files shredder. It currently has downloads for Linux, Windows, and Mac.

I'm not the developer, but it's a great light resource for quick and secure encryption.

[samuel-lucas6]

Disclaimer: I'm biased because I'm the developer of a similar tool and got into a spat with Evan/HACKERALERT, but I'll try and be objective with the following comments.

I'm still in two minds about Picocrypt. On the one hand, it's a handy GUI version of tools like age. However, there are various things that can be critiqued, some of which I'm not convinced the developer is willing to accept based on my discussions with him. For instance:

• The code is very difficult to read and needs to be separated up.
• The unhelpful names and number of commits makes assessing changes difficult.
• The 'paranoid mode' is unnecessary, adds more code, and confuses the user. Cipher agility and cascade encryption are frowned upon in the cryptography community. VeraCrypt is another bad example of this. Things should be simple, secure by default, and unadjustable.
• Random nonces are being used when it makes more sense to use a counter nonce, which would save storage space and be marginally more efficient.
• The Internals (technical details) file should be more detailed.
• The checksum and shredder features are also unnecessary for an encryption tool and add more code. They should be separate tools.
• The developer has made some inaccurate statements, is still making inaccurate statements, and rejected my feedback multiple times before eventually agreeing with me and implementing some of my suggestions after discussusion broke down. For instance, he was originally against using BLAKE2b completely but has now implemented it, he's now using Encrypt-then-MAC instead of ChaCha20-Poly1305, and he thought ChaCha20-Poly1305 from go/crypto was less secure than Monocypher (because he said it was unaudited) but was using Argon2 from go/crypto (by that logic, also unaudited) and has now ditched Monocypher for ChaCha20 completely. The fact that he was not that willing to admit that he was wrong and continues to spread misinformation, such as 'BLAKE3 is a solid non-cryptographic checksum, it is not so good as a cryptographic hash function' and 'the relatively insecure SHA2', is concerning in my opinion.
• Lastly, the developer kept dragging the conversation in the PrivacyTools issue to Picocrypt vs Kryptor for no good reason before slandering me on Reddit and GitHub. I'll admit I was too heavy handed with some of my replies, but his response was out of line.

I'll leave it for other people to decide whether the program should be added.

Update (10/12/21)

• The shredder has been removed as of v1.21.
• The Internals.md file hasn't been changed.
• The SECURITY.md file was removed in favour of security advisories, so I've reported that it's not possible for people to create security advisories since only admins can. Hopefully the SECURITY.md file will be restored. Edit: It has been.
• There's still a normal mode, fast mode, and paranoid mode. The fast mode is for 'low-sensitivity files' according to the README. I still strongly disagree with this distinction. The tool should be considered secure no matter the input. Furthermore, XChaCha20-BLAKE2b has a high security margin, just like XChaCha20-SHA3, so the statement is misleading.
• The code hasn't changed much.
• The commit names could still be improved.
• A random nonce per file is now being used. This suggests the implementation is a regular Encrypt-then-MAC rather than chunked encryption.

[samuel-lucas6]

Also, I am considering to change HMAC-SHA3 to keyed Blake2b, like you do with Kryptor. There is a significant speed difference, and I don't think an authentication code needs to be so "overkill", as you have correctly stated before. I still love SHA3, and security critical components like storing the hash of the encryption key will be done with SHA3, but I am considering speeding up the authentication process and switching to Blake2b. I thinking now that this would be the best choice, and HMAC-SHA3 will still be the default for paranoid mode.

Thank you for taking on the feedback. I take it that means getting rid of the fast mode option and just having a normal and paranoid mode? I think that would be better too. Using just one algorithm would be more consistent, but I understand where you're coming from. Even just switching from HMAC-SHA3 to regular SHA3 or SHAKE with a key would result in a speed improvement if you still want something SHA3.

@ph00lt0 I expect SHA3 will prove to be more secure than SHA2. It certainly has a good security margin, has been well analysed, and fixes the length extension attacks issue. Hardware support really would help on the speed side.

thanks for pointing out the misleading fast mode terms. Since I will be switching normal mode to Blake2b, I will be updating the readme soon and I will clarify that. Also, what do you recommend I should update the Internals.md with?

I am bad at naming my commits haha. I'll try to be more descriptive with them from now on.

I know it's annoying to have to write more lol. That's great though. The file format is the main thing, like documenting the headers. Just a summary of the most important code really to save someone from and aid someone looking at the code.

[HACKERALERT]

Yes, I am planning to remove the fast mode. Now that normal mode is using BLAKE2, there really is no difference between fast and normal, apart from Argon2 differences. Removing the fast mode would allow me to not worry about the misleading wording, and provide less cryptographic agility, as you have described before. I'll keep paranoid mode since the comfort of an added cipher is appealing to some (including me, when I encrypt my cryptocurrency keys).

And great point about the file header documentation. I'll do something similar to age's specification. Thank you for the help.

[HACKERALERT]

@samuel-lucas6 Success! I've removed the fast mode and changed the default mode to use a keyed Blake2b. Indeed, I feel things are cleaner now, with the normal mode being good for 99% of use cases, and the paranoid mode as a nice add-on for the other 1% :). There should no longer be any confusion or hesitation about which mode to use. When I release the next version with these updates, I'll be able to remove the fast mode section from the README, which should clean things up. As it stands,
Normal mode: Argon2 with 4 passes, 1GB memory, and 4 threads. XChaCha20 authenticated by Blake2b.
Paranoid mode: Argon2 with 8 passes, 1GB memory, and 8 threads. XChaCha20-Serpent authenticated by HMAC-SHA3.
I'll update the Internals accordingly once I get things sorted out. Thanks for your suggestions that I now completely agree with ;)

[samuel-lucas6]

Nicely done!

[HACKERALERT]

I'm releasing v1.22 which removes the fast mode and swaps HMAC-SHA3 for BLAKE2b. I'm pretty busy at this time, so I might not get to updating the Internals.md accordingly yet, but I'll do it as soon as I have the chance.

[HACKERALERT]

I strongly believe that, as the author of Picocrypt, it should be added to Privacy Guides. While I don't want to write a multi-page-long essay, there are a few important points I would like to highlight and will do so in the following paragraphs.

To start, this discussion was not opened by me. The fact that a Picocrypt user took the time and initiative to create this discussion shows that there are people who believe that Picocrypt is worthy of adding to this awesome set of tools/guides. It's not just me pushing this forward, but also many of Picocrypt's users. The atmosphere of Picocrypt's subreddit is always positive and supportive. When I need some testers, there are people who voluntarily do testing on their machines, spin up VMs, and assist me with many of the tasks that I cannot do alone. Picocrypt has arguably one of the strongest communities out of all encryption tools, and that gives it the power to become better for everyone. How often do you see a dev within 24 hours of reach, spending over a hundred hours on a FOSS project, and making multiple posts each month to integrate feedback and connect with users? 😄

Picocrypt is an open-source encryption tool designed to be small in size, simple to use, yet highly secure. It's portable, dependency-free, and available for all three major platforms, and the executables don't require any root/admin privileges. There are no ads or telemetry, and the code is entirely open for viewing, with detailed instructions for building from source. And unlike some other tools, Picocrypt is a graphical application with a carefully thought out and community-contributed user interface. Not only is the GUI lightweight and featureful, but it's also intuitive and easy to use. Simplicity is an important part of Picocrypt because one of my goals was to make encryption simpler for everyone so that "non-technical" people like artists, doctors, etc. can have a highly secure tool they can trust, knowing that, unlike other complicated tools, there's no potential for a foot-gun as long as their password is well-chosen (which is why there is also a password and keyfile generator).

And guess what? Picocrypt doesn't sacrifice customizability for simplicity. Not only is Picocrypt simple to use, but it's also highly customizable with loads of features and use-cases. For example, one of Picocrypt's features is Reed-Solomon encoding, which will encode all of your data with Reed-Solomon (an error correction code) to ensure that Picocrypt can recover broken bits and bytes if they corrupt. What's more, Picocrypt by default will encode the header, since it is the most important part of an encrypted volume. Very few tools, if any, do this by default to protect the salts, nonce, etc. Picocrypt does many precautions automatically, meaning that not only does the user not have to take any manual action, but also that if something does go wrong, Picocrypt will be resilient in handling it. 💪

In addition to encryption, Picocrypt can also generate checksums and securely shred files (removed because it was hard to maintain and not as effective as FDE). It's jam-packed with features, even though it's only 3MB in size. The wide variety of use cases while having a straightforward and lightweight UI puts Picocrypt in an advantageous position when compared to something like 7-Zip. And because all cryptography (except for Serpent) is done by the well-known and standard golang.org/x/crypto modules, users can rest assured that the low-level primitives are well-built and secure. 🔐

And with over 2k downloads, 250+ stars, ~100 active Snapcraft installs, $150+ donations, and ~200 subredditors, there are many reasons why it would help if Picocrypt was appended in the "Worth mentioning"... Not just for me, but for the future users who will find Picocrypt to be a valuable and reliable tool. And I'm sure that the many users of Picocrypt have my back on this.

Here's a post in r/PrivacyToolsIO about Picocrypt that was taken very positively: https://www.reddit.com/r/privacytoolsIO/comments/m8jpu6/picocrypt_a_foss_3mb_encryption_tool/
Here's the homepage: https://github.com/HACKERALERT/Picocrypt

I really hope that after more than half a year since my request on the old Privacy Tools issue page, we will make some progress on this. Picocrypt has grown considerably since then and is still constantly growing, with new users every day. Will Privacy Guides accept this privacy and security enhancing FOSS project? 🚀 🚀 🚀

Sincerely,
Evan Su

[ph00lt0]

@samuel-lucas6 https://keccak.team/2017/is_sha3_slow.html

[samuel-lucas6]

@samuel-lucas6 https://keccak.team/2017/is_sha3_slow.html

I have read that blog post before, and it proves my point. KangarooTwelve is significantly faster, but it's not accessible. SHAKE is still slower than SHA2 and less accessible than SHA3 as well. SHA3 has the same problem as BLAKE2 with the number of variants, which is something nice about BLAKE3.

[HACKERALERT]

@samuel-lucas6 I would love to put the past aside and continue constructively :). Your point about SHA3 being slow has lead me to consider switching to Blake2, as mentioned in another comment (I probably will). So I definitely thank you for persisting with it and giving me your opinions.

Btw, I am also impressed by your Cryptography-Guidelines repo and how you link to many different papers and go in depth. It's well written!

[samuel-lucas6]

Awesome @HACKERALERT. Thanks, it's a work in progress :)

[efb4f5ff-1298-471a-8973-3d47447115dc]

Whoo-hoo @samuel-lucas6 and @HACKERALERT are going along again🎉

[ihubgit]

Hi, just dropping a small word here as a non-geek end user who was looking for an easy to use, security focused, UI based and cross-platform FOSS encryption app. I discovered Picocrypt by chance a few months ago and it ticked all the above cases. Sure, there's CLI alternatives out there for the *nix guys, but for the ordinary dude, a UI does matter.
I'm one of the guys interacting with the dev on his subreddit and frankly, i can only confirm what he states in his above post. The initial post here wasn't started by him and he's only responding to (rather harsh and probably unmerited) criticism. I've always found him very eager to interact with and hear feedback from his users. I've never seen him initiating attacks on anyone, as some participants in this post do, which is telling on a more personal level.
Sure enough, anyone ought to be open to criticism and remarks on the objective level of the quality of an encryption app, but from all Evan/HACKERALERT's posts both here and in reddit, i can only see that he does take into account valid remarks and remains constructive with his interlocutor.
As far as i can tell from his posts and replies to his woes, he does seem to have a fair amount of technical skills concerning encryption and the app seems solid and trustworthy.
I'm not sure he'll be able to pull off the necessary funding for a security audit, which is a problem for all FOSS devs anyway, but wish him luck with it.
Maybe there's a way, a forum, to get a peer review by a voluntary third party for the app's code so to confirm it passes a security screening ? That might confirm the trustworthiness of the app.
I do believe Picocrypt has the right to be listed as a solid encryption app on the website so users can have one more choice, which is always a good thing.

[HACKERALERT]

Thanks for your view and support! An audit is indeed difficult to pay for, considering the free and open nature of Picocrypt. I am looking into sponsorships, grants, etc. and hopefully one of my appeals will be successful at some point in the future. Every Picocrypt release is screened with CodeQL, an automated code security scanner, so any basic issues would have been caught, and a basic level of security is guaranteed. And since all cryptography is from Go's x/crypto modules, there shouldn't be any implementation errors either 😄.

[SkewedZeppelin]

Slight OT:
As a user why would one use Kryptor or Picocrypt over age/gpg (encrypted file sharing) or gocryptfs (encrypted folder) or luks (full drive encryption) or restic/borg (encrypted backups)?

The first two even have nice Android apps such as Open Keychain and DroidFS.

[samuel-lucas6]

I would say you could link the golang crypto module. 'XOR the hashes together' instead of 'XORs'. 'XORed with the master key'. 'keyfile hashes are XORed with each other doesn't matter - the end result is the same'. Maybe get rid of 'combine' and just say 'concatenate' the files together. What gave you the idea for the keyfile ordering? It sounds a bit risky having to remember an order. I think the actual chunk encryption should be explained so it's clear how the nonce is being used, where the authentication tag is placed, how large the chunks are, how the length of the combined chunks/final chunk is checked, how chunk reordering is prevented, etc.

[HACKERALERT]

Thank you for the feedback! I'll link the Go crypto module and clarify some terms later today.

Keyfile ordering is disabled by default, so I would assume that if one chooses it, they will remember the order. And if they don't, that is kind of on them 🤷 .

Also, there is no chunking. Since ChaCha20 is a stream cipher, Picocrypt uses the same cipher object with the same key and nonce, but progressively encrypts in 1mb buffers. So there's no chunking going on. I guess maybe I should clarify that though.

[samuel-lucas6]

Ah now I remember you saying. Perfect example of why that should be written down!

[HACKERALERT]

@dngray Would you mind changing the link from evansu.cc/picocrypt back to github.com/HACKERALERT/Picocrypt? I decided to try hosting a webpage for Picocrypt a long time ago, but it is too much work and if I change one thing on GitHub, I have to mirror the changes over to my site. I've decided now to just use the GitHub repo as the official homepage and have my site redirect. Thanks.

[dngray]

Can do, sorry for changing it wrong. privacyguides/privacyguides.org@aabc582

[dngray]

This was added when we did the migration privacyguides/privacyguides.org@8ef8e2a