🆕 Software Suggestion | Picocrypt

[HACKERALERT]

Basic Information

Name: Picocrypt Category: Encryption tools URL: https://github.com/HACKERALERT/Picocrypt

Description

Picocrypt is a very small (3MB), very simple, and very secure encryption tool. I built it with security and simplicity in mind. It is meant to allow anyone to securely encrypt their files, without having to go through the hassle of creating VeraCrypt volumes, or risk the security of their data by using something insecure (ie. 7-Zip). It uses the secure XChaCha20 cipher as well as the respected Argon2 key derivation function. Authentication is done by HMAC-SHA3 and core encryption is done by Go's standard golang.org/x/crypto/chacha20 package.

Why I am making the suggestion

Often, people choose not to encrypt their files because it is hard to do. I created Picocrypt with the vision that due to its simplicity, it'll be used and adopted by a wider range of people (writers, artists, freelancers), and not just "techy" people. Most people don't encrypt their files or don't care about privacy because it's too hard to do correctly. Picocrypt fixes that stereotype by providing a super-simple, but super-secure (and foolproof) encryption tool. Picocrypt has also gathered a lot of attention and positive feedback on this PrivacyTools Reddit thread, which suggests that it should be considered to be added to the list of FOSS software.

My connection with the software

I am the author of Picocrypt, and I love helping people stay private and secure. I have a solid understanding of cryptography, and so I can (almost) guarantee the security of Picocrypt. I intend on getting it audited, with monetary support from donations (when and if possible).

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

[samuel-lucas6]

Hi @HACKERALERT, I'm the maintainer of Kryptor, and considering how your tool appears to be more popular than mine, I'm very surprised nobody has commented on this yet. I haven't been active in the PrivacyTools repo recently, so I'm sorry for not commenting sooner. Another thing I should mention is that I'm currently in the middle of an exam period, so I haven't spent much time looking into your program. Therefore, I apologise in advance if anything I say is incorrect or if anything I ask has been answered somewhere already. Lastly, even though our programs are somewhat in competition, please don't see my criticism as me trying to bash your project.

Questions

1. Why are you using SHA3 to check whether the key is correct instead of just viewing an error from XChaCha20-Poly1305 as the key being incorrect?
2. Why did you choose 1 MiB chunks? That seems a bit high in terms of the amount of extra data being stored and reduces the forgery bounds for XChaCha20-Poly1305.
3. Why are you randomly generating a nonce for each chunk rather than incrementing the nonce? Incrementing the nonce would be faster, and then you only have to store one nonce, which would save space and simplify the format.
4. How are you preventing chunk reordering/removal/duplication? Is that via the nonce encryption?
5. How are you preventing truncation of encrypted files?
6. Why are you using SHA3 for file corruption checks when XChaCha20-Poly1305 can handle that? Is that something to do with the Reed-Solomon parity bytes?
7. What's your justification for the file shredder and file checksum generator features?
8. Where did the $8,500 figure for an audit come from? Your program isn't that many lines.

Feedback

• Hashing a key typically isn't recommended.
• I would get rid of the file shredder and file checksum generator features. Those sort of features should be separate tools, and that would simplify the program even more.
• I suggest you stop asking for donations for an audit because there's no way you'll be able to fund an audit that way. Barely anybody donates to open source projects compared to how many people use them, and as you've mentioned, an audit costs thousands of dollars. You'd be better off creating a bug bounty program on something like HackerOne to get some more people checking the source code. Unfortunately, that's really the best we can do since applying for funding is a waste of time unless the project is extremely popular.
• Some of the indentation in your code makes things harder to read, but I'm not a fan of Golang for readability anyway.
• It looks like your code needs to be split up into more subroutines.
• There are a few commented out chunks of code that should probably be removed.
• I don't think you should branch out into disk encryption as well as file encryption unless you intend to make a separate tool. Disk encryption is a lot more complicated than file encryption.
• I don't understand why everybody wants Android/iOS support for file encryption tools. Do people really use their phone to look at files? I wouldn't bother since it'll require a lot more work, and I expect very few people actually encrypt/decrypt files on their phone. The most popular encryption tools like age are just for PC.
• There are some spelling and grammar mistakes in the Internals.md file.
• The Reed-Solomon feature sounds interesting.
• Good job picking decent Argon2 parameters.
• Monocypher was a good choice, although it's slower than libsodium.

Hopefully you find some of this feedback helpful. I look forward to hearing your answers to my questions. I best be off now as I'm already 15 minutes late to my revision session and have an exam tomorrow.

[HACKERALERT]

@samuel-lucas6 Thank you for your suggestions. Good luck with your exam(s)!

Therefore, I apologise in advance if anything I say is incorrect or if anything I ask has been answered somewhere already.

Don't worry about it! I appreciate your efforts. Taking the time to review my project and software is a very kind act. Thank you!

Lastly, even though our programs are somewhat in competition, please don't see my criticism as me trying to bash your project.

Same to you. I think that while Picocrypt and Kryptor are similar, each has different use cases. While Kryptor is more CLI-oriented, Picocrypt is more GUI-oriented. Since they're both not commercial software, there's no need for attacking each other 👍. With open-source security software, a little competition and criticism is a good safety net.

Why are you using SHA3 to check whether the key is correct instead of just viewing an error from XChaCha20-Poly1305 as the key being incorrect?

Great question! I use a SHA3 hash to validate the key because if I only used XChaCha20-Poly1305, it would be impossible to differentiate between a bad key and corrupted data. For example, if the key is correct, but the data is corrupted and/or modified, I can't blame the key for that, right?

Why did you choose 1 MiB chunks? That seems a bit high in terms of the amount of extra data being stored and reduces the forgery bounds for XChaCha20-Poly1305.

In previous, Picocrypt was written in Python and encryption was done in 1 MiB chunks, but with the same cipher (incremental encryption). Because I've rewritten it in Go and Monocypher doesn't provide an incremental encryption interface (well, it does, but I don't want to roll my own implementation), I'm encrypting data in 1MB chunks instead, which doesn't compromise security, and even benefits Picocrypt by removing the 256 GB size limit of ChaCha20. There's not a lot of extra data being stored. All that's added is a 24-byte nonce which after Reed-Solomon becomes 152 (24+128) bytes, and a 16 byte Poly1305. 16+152=168, (1048576+168)/1048576=1.00016, which is a extremely minuscule increase in size. There was a good StackOverflow thread which justifies these choices.

Why are you randomly generating a nonce for each chunk rather than incrementing the nonce? Incrementing the nonce would be faster, and then you only have to store one nonce, which would save space and simplify the format.

Doing so would increase the chance of a nonce collision. By generating a random nonce each time, I'm spreading out the nonces evenly across the 192-bit field. If the nonces were consecutive, an attacker could try all nonces much faster, and the chance of a nonce collision would be higher. By generating random nonces, a hacker can't just choose a starting nonce and get a hold of all the nonces after. Picocrypt makes no compromises for security, and choosing random nonces is the most secure.

How are you preventing chunk reordering/removal/duplication? Is that via the nonce encryption?

Correct. Encrypting the nonces is not to protect them, but to put a layer of Poly1305 on top to ensure that the order is correct. Removal/duplications are prevented because they would cause the file size to change. Picocrypt calculates the number of chunks by subtracting the header size from the total size and dividing by the size of 1 MiB plus the nonce and Poly1305. If a chunk was to be removed, there would be one too many nonces, and the last nonce would be read as part of the data, which would make Poly1305 fail if that makes sense. If you're confused, the important part here is that the file size is critical. If it changes in any way, decryption will fail. The addition of a block follows the same logic.

How are you preventing truncation of encrypted files?

Truncating a file is essentially removing chunks of data, so it is explained by my response above.

Why are you using SHA3 for file corruption checks when XChaCha20-Poly1305 can handle that? Is that something to do with the Reed-Solomon parity bytes?

Actually, I used BLAKE3, not SHA3. But that was in previous versions. In the latest version in Go, I have removed the BLAKE3 hash and rely on Poly1305. My original reasoning was that it would allow me to differentiate between corrupted data and intentionally modified data. If the data was corrupted, both the BLAKE3 and Poly1305s would fail. If it was intentionally modified, the hacker would update the BLAKE3 hash to fit the modified data, so it would pass, but the Poly1305s fail. Of course, a hacker can just not update the hash and make it look like the file is corrupted, which made the hash useless, so I removed it.

What's your justification for the file shredder and file checksum generator features?

One of Picocrypt's goals is to make security accessible to a wider variety of people. By including features like a file shredder with an encryption tool, it's easier for non-technical people (artists, authors, etc.) to have all tools in one place, and implemented correctly (after an audit of course).

Where did the $8,500 figure for an audit come from? Your program isn't that many lines.

Indeed it is not, but $8,500 is the direct response from Cure53: Converting 6900 euros to USD at the time yielded $8,500. It should be noted that that's the cost for the Python version and would include an audit of the crypto library. In the latest version, I used Monocypher, which is already an audited crypto library, so if I was to ask for a quote again this time, it would be substantially lower because an audit and a crypto library would not be included.

Now to address some of your feedback (thank you for it!)

Hashing a key typically isn't recommended.

Actually, I think you mean "Hashing a password typically isn't recommended.". Hashing a key is fine because a secure random salt is used in Argon2, so the key is different every time. And since the hash takes in a 256-bit key and outputs a 256-bit hash, no security is lost and no brute force is possible because the field is still 256-bits.

I suggest you stop asking for donations for an audit because there's no way you'll be able to fund an audit that way. Barely anybody donates to open source projects compared to how many people use them, and as you've mentioned, an audit costs thousands of dollars. You'd be better off creating a bug bounty program on something like HackerOne to get some more people checking the source code. Unfortunately, that's really the best we can do since applying for funding is a waste of time unless the project is extremely popular.

Me too. Originally, I never asked for donations and I never even thought about it. Picocrypt was a personal project that I wanted to share with others. But many people on Reddit wanted to get it audited and would be willing to donate. And there have been donators. Since the latest version uses an already audited crypto library, I'll ask Cure53 for a quote again and it will be much lower. If it's <$3k, I think it would still be something that I would be willing to ask for donations for. After all, an audit would make things more secure and more trustable.

Some of the indentation in your code makes things harder to read, but I'm not a fan of Golang for readability anyway.

Yes, I know. The version you are reading is the first version written in Go, so the formatting is a little barbaric for the time being.

It looks like your code needs to be split up into more subroutines.

Yup. Currently, almost everything is in the work() function. As I start to add CLI support, I'll split up core components to make it easier to integrate with the CLI, and also make it a Go library so others can use its core functions.

There are a few commented out chunks of code that should probably be removed.

Yeah, most of those sections were experimental and will be removed soon.

I don't think you should branch out into disk encryption as well as file encryption unless you intend to make a separate tool. Disk encryption is a lot more complicated than file encryption.

I don't think I will, given the complexity of such things as proven by VeraCrypt. I have it in the Roadmap as a consideration (people can create pull requests toward full-disk encryption), but I don't think I'll add it personally, as it's a lot of work to implement correctly.

I don't understand why everybody wants Android/iOS support for file encryption tools. Do people really use their phone to look at files? I wouldn't bother since it'll require a lot more work, and I expect very few people actually encrypt/decrypt files on their phone. The most popular encryption tools like age are just for PC.

I'm not sure why either! Like, how is a phone going to be able to deal with Argon2 which is so computationally intensive? And why would your sensitive files be on your phone, which could get stolen? Golang does have Android support, which is why I added this to the Roadmap. Might as well give it a try, if it's supported, right?

There are some spelling and grammar mistakes in the Internals.md file.

It is a work in progress... ;)

Monocypher was a good choice, although it's slower than libsodium.

Security over speed is what Picocrypt values. I don't care how fast libsodium is; Monocypher is audited and is more secure. From the homepage: It's designed for maximal security, making absolutely no compromises security-wise, and is built with an audited cryptography library.

Conclusion

Thank you for carving some time out of your packed schedule to give me some feedback and criticism. Your points have been useful and helped me look at things from another perspective. It's nice to have a different pair of eyes to criticize it. As well, hopefully, through my answers, you have noticed that I have put a lot of thought and effort into designing Picocrypt.

Sorry if this was a long reply, but it should contain a healthy amount of content. I'm sorry to see that Kryptor hasn't gotten much attention as Picocrypt, even though it's more mature. I certainly respect how simple and cross-platform Kryptor is; I've been trying to build Picocrypt for macOS for the past few days and it's giving me headaches because of static linking issues and OpenGL support. Also, I think that a GUI might help your project gain more traction, even though your CLI already has a plethora of features. Limiting your cohort of users to terminal users is likely limiting Kryptor's popularity. From my experience with Picocrypt's subreddit, a large portion of Picocrypt fans are not familiar with command line stuff.

Wish you all the best with Kryptor and thanks again for your valuable feedback!

[samuel-lucas6]

@HACKERALERT Many thanks!

Great question! I use a SHA3 hash to validate the key because if I only used XChaCha20-Poly1305, it would be impossible to differentiate between a bad key and corrupted data. For example, if the key is correct, but the data is corrupted and/or modified, I can't blame the key for that, right?

I see, but why do you need to differentiate between the wrong key and a corruption? Are you providing a different error message? Is it something to do with the recovery of corrupted files?

In previous, Picocrypt was written in Python and encryption was done in 1 MiB chunks, but with the same cipher (incremental encryption). Because I've rewritten it in Go and Monocypher doesn't provide an incremental encryption interface (well, it does, but I don't want to roll my own implementation), I'm encrypting data in 1MB chunks instead, which doesn't compromise security, and even benefits Picocrypt by removing the 256 GB size limit of ChaCha20. There's not a lot of extra data being stored. All that's added is a 24-byte nonce which after Reed-Solomon becomes 152 (24+128) bytes, and a 16 byte Poly1305. 16+152=168, (1048576+168)/1048576=1.00016, which is a extremely minuscule increase in size. There was a good StackOverflow thread which justifies these choices.

I understand what you mean. I meant that if the last chunk only contains 1 byte of plaintext to be encrypted, then the ciphertext chunk will be padded out to 1 MiB rather than 16 or 32 KiB. How are you handling files less than 1 MiB?

Doing so would increase the chance of a nonce collision. By generating a random nonce each time, I'm spreading out the nonces evenly across the 192-bit field. If the nonces were consecutive, an attacker could try all nonces much faster, and the chance of a nonce collision would be higher. By generating random nonces, a hacker can't just choose a starting nonce and get a hold of all the nonces after. Picocrypt makes no compromises for security, and choosing random nonces is the most secure.

I get where you're coming from, but there's really nothing wrong with having a counter nonce. If you were just using ChaCha20-Poly1305, then you'd have to use a counter nonce, with maybe a few rare exceptions. The recommended approach for XChaCha20-Poly1305 is typically to generate a random nonce and then increment it for each chunk. The nonce doesn't need to be secret, and even using a fixed nonce (e.g. a nonce of 0) won't realistically lead to a nonce collision assuming everything else has been done appropriately (e.g. you're using a random key each time).

I think you should reconsider this one because it would be a much simpler approach. It's faster, reduces the amount of data to store, and doesn't realistically sacrifice security.

Correct. Encrypting the nonces is not to protect them, but to put a layer of Poly1305 on top to ensure that the order is correct. Removal/duplications are prevented because they would cause the file size to change. Picocrypt calculates the number of chunks by subtracting the header size from the total size and dividing by the size of 1 MiB plus the nonce and Poly1305. If a chunk was to be removed, there would be one too many nonces, and the last nonce would be read as part of the data, which would make Poly1305 fail if that makes sense. If you're confused, the important part here is that the file size is critical. If it changes in any way, decryption will fail. The addition of a block follows the same logic.

If you used a counter nonce, then that would also provide protection against chunk reordering, removal, etc. It's good to hear that you're checking the file size; that's what Kryptor does too.

Actually, I used BLAKE3, not SHA3. But that was in previous versions. In the latest version in Go, I have removed the BLAKE3 hash and rely on Poly1305. My original reasoning was that it would allow me to differentiate between corrupted data and intentionally modified data. If the data was corrupted, both the BLAKE3 and Poly1305s would fail. If it was intentionally modified, the hacker would update the BLAKE3 hash to fit the modified data, so it would pass, but the Poly1305s fail. Of course, a hacker can just not update the hash and make it look like the file is corrupted, which made the hash useless, so I removed it.

Right. I read that you were using SHA3-512 on Reddit.

One of Picocrypt's goals is to make security accessible to a wider variety of people. By including features like a file shredder with an encryption tool, it's easier for non-technical people (artists, authors, etc.) to have all tools in one place, and implemented correctly (after an audit of course).

That's a good goal, but I don't think many people actually rely on file shredding software since it really can't make any guarantees. I had a file shredding feature in several of the first versions of Kryptor, but I removed it for those reasons. On the other hand, you can argue it's relevant in terms of disposing of decrypted files after you're done with them. It's still extra code though.

Converting 6900 euros to USD at the time yielded $8,500. It should be noted that that's the cost for the Python version and would include an audit of the crypto library. In the latest version, I used Monocypher, which is already an audited crypto library, so if I was to ask for a quote again this time, it would be substantially lower because an audit and a crypto library would not be included.

I never got an actual quote, but I did reach out to Cure53 out of interest, and Mario said around $5,000 for a small program I think, which is typically the minimum amount of funding you can get from a grant. I expect it would drop down to that sort of figure but not much lower.

I tried contacting a few individuals about potentially performing an audit, but none of them replied. I'd like to think that they would be cheaper.

Actually, I think you mean "Hashing a password typically isn't recommended.". Hashing a key is fine because a secure random salt is used in Argon2, so the key is different every time. And since the hash takes in a 256-bit key and outputs a 256-bit hash, no security is lost and no brute force is possible because the field is still 256-bits.

That's definitely something to avoid with a regular hash function, but I was referring to it not being common practice as far as I'm aware. However, it should be fine. The collision resistance for 256-bit hashes is only 128-bits though.

Me too. Originally, I never asked for donations and I never even thought about it. Picocrypt was a personal project that I wanted to share with others. But many people on Reddit wanted to get it audited and would be willing to donate. And there have been donators. Since the latest version uses an already audited crypto library, I'll ask Cure53 for a quote again and it will be much lower. If it's <$3k, I think it would still be something that I would be willing to ask for donations for. After all, an audit would make things more secure and more trustable.

Even $3,000 is a lot of revenue. Wireguard gets a lot of donations but not much else comes to mind. An audit does help with gaining trust, but it's a bit of a scam really since it's extremely expensive, and as soon as you modify the code, you can reintroduce a vulnerability. Audits are for companies really.

I don't think I will, given the complexity of such things as proven by VeraCrypt. I have it in the Roadmap as a consideration (people can create pull requests toward full-disk encryption), but I don't think I'll add it personally, as it's a lot of work to implement correctly.

I suggest you come up with a specific list of goals so you don't allow people to overcomplicate things. File and disk encryption in one tool would be a bit much.

I'm not sure why either! Like, how is a phone going to be able to deal with Argon2 which is so computationally intensive? And why would your sensitive files be on your phone, which could get stolen? Golang does have Android support, which is why I added this to the Roadmap. Might as well give it a try, if it's supported, right?

If you're willing to put the time in, then fair enough. However, the more different versions you do, the more chaotic and hassly open source development becomes, which is I think what causes people to end up abandoning their projects. Since you're not being paid, you don't want to overdo it.

Security over speed is what Picocrypt values. I don't care how fast libsodium is; Monocypher is audited and is more secure. From the homepage: It's designed for maximal security, making absolutely no compromises security-wise, and is built with an audited cryptography library.

Libsodium was audited in 2017 and is one of the most popular cryptographic libraries, which means more people paying attention to the code. Whilst I've not got along with Frank, he definitely knows what he's doing. I really don't think it's fair to say that Monocypher is more secure. In fact, Moncypher only offers Argon2i, which is vulnerable to an attack unless you use more than 10 iterations. Then useability wise, I think libsodium is considerably better. For instance, the libsodium documentation is pretty detailed and easy to read. Libsodium also offers access to more algorithms and is noticeably faster. More speed without a loss in security is no bad thing. Speed should honestly be a priority.

Thank you for carving some time out of your packed schedule to give me some feedback and criticism. Your points have been useful and helped me look at things from another perspective. It's nice to have a different pair of eyes to criticize it. As well, hopefully, through my answers, you have noticed that I have put a lot of thought and effort into designing Picocrypt.

No problem. You have thought things through, although I must insist that a few of my recommendations would be beneficial. I'd like to hear what @lynn-stephenson has to say about your program.

I'm sorry to see that Kryptor hasn't gotten much attention as Picocrypt, even though it's more mature. I certainly respect how simple and cross-platform Kryptor is; I've been trying to build Picocrypt for macOS for the past few days and it's giving me headaches because of static linking issues and OpenGL support. Also, I think that a GUI might help your project gain more traction, even though your CLI already has a plethora of features. Limiting your cohort of users to terminal users is likely limiting Kryptor's popularity. From my experience with Picocrypt's subreddit, a large portion of Picocrypt fans are not familiar with command line stuff.

Kryptor was originally a GUI application, but I switched to CLI only because a) it's much easier for cross-platform development, b) it didn't make much sense to be working on two separate versions of the program at the same time, and c) some of the features (e.g. file signing, private key encryption, etc) would be difficult to do in a GUI format. I like a GUI, but I have come to appreciate CLI programs more, and if they don't have too many commands and there's a good tutorial, then it should still be accessible for anybody willing to give it a go.

[HACKERALERT]

I see, but why do you need to differentiate between the wrong key and a corruption? Are you providing a different error message? Is it something to do with the recovery of corrupted files?

Yes, I show different error messages. The reason why I added a Reed-Solomon feature is because it's suitable for creating long-term archives that could be stored on a hard drive for a long time. Sometimes, data might corrupt so much that Reed-Solomon can't fix it, or the user might not have toggled the feature, so I would show a message saying that the data is corrupted, instead of assuming that the data is intact and that the password is incorrect.

I understand what you mean. I meant that if the last chunk only contains 1 byte of plaintext to be encrypted, then the ciphertext chunk will be padded out to 1 MiB rather than 16 or 32 KiB. How are you handling files less than 1 MiB?

If I'm understanding you correctly, you're wondering how I prevent a hacker from adding/removing bytes when the chunk is padded? Well, while a hacker can add data to incomplete chunks as they wish, the Poly1305 won't pass. Either Poly1305 will catch the hacker, or the change in size would.

I get where you're coming from, but there's really nothing wrong with having a counter nonce. If you were just using ChaCha20-Poly1305, then you'd have to use a counter nonce, with maybe a few rare exceptions. The recommended approach for XChaCha20-Poly1305 is typically to generate a random nonce and then increment it for each chunk. The nonce doesn't need to be secret, and even using a fixed nonce (e.g. a nonce of 0) won't realistically lead to a nonce collision assuming everything else has been done appropriately (e.g. you're using a random key each time). I think you should reconsider this one because it would be a much simpler approach. It's faster, reduces the amount of data to store, and doesn't realistically sacrifice security.

You've got a point. Thinking about this a little more, I think that is what I will do indeed. It will prevent chunk reordering, and not require me to go through the hassle of generating random nonces and then encrypting them at the end. Seems quite reasonable to me, thanks!

Right. I read that you were using SHA3-512 on Reddit.

Sorry for the confusion. I used to use SHA3 for hashing the key, and BLAKE3 for corruption checks. I removed BLAKE3 in the latest version so the three core components are just Argon2, SHA3, and XChaCha20-Poly1305.

That's a good goal, but I don't think many people actually rely on file shredding software since it really can't make any guarantees. I had a file shredding feature in several of the first versions of Kryptor, but I removed it for those reasons. On the other hand, you can argue it's relevant in terms of disposing of decrypted files after you're done with them. It's still extra code though.

I debated a while ago whether I should add it or not, with all the pain regarding shredding files on an SSD. But I decided, in the end, to add it, because it was straightforward to implement and was only ~300 lines I think.

I never got an actual quote, but I did reach out to Cure53 out of interest, and Mario said around $5,000 for a small program I think, which is typically the minimum amount of funding you can get from a grant. I expect it would drop down to that sort of figure but not much lower. I tried contacting a few individuals about potentially performing an audit, but none of them replied. I'd like to think that they would be cheaper.

Ouch. I've just contacted them and I'll let you know the reply.

That's definitely something to avoid with a regular hash function, but I was referring to it not being common practice as far as I'm aware. However, it should be fine. The collision resistance for 256-bit hashes is only 128-bits though.

Sorry, my bad for forgetting that I'm using SHA3-512, not 256. So that would offer 256-bit security.

Even $3,000 is a lot of revenue. Wireguard gets a lot of donations but not much else comes to mind. An audit does help with gaining trust, but it's a bit of a scam really since it's extremely expensive, and as soon as you modify the code, you can reintroduce a vulnerability. Audits are for companies really.

Honestly, you're quite correct. It's a pity that we as devs spend many unpaid and voluntary hours on these projects and barely get any funding or support. Even if I don't get an audit, at least people can be reassured that Picocrypt uses an audited crypto library.

I suggest you come up with a specific list of goals so you don't allow people to overcomplicate things. File and disk encryption in one tool would be a bit much.

Yup. I'm giving up disk encryption, although I'm considering volume-based encryption as a potential feature.

If you're willing to put the time in, then fair enough. However, the more different versions you do, the more chaotic and hassly open source development becomes, which is I think what causes people to end up abandoning their projects. Since you're not being paid, you don't want to overdo it.

It's actually pretty simple. IIRC, I just need to install Android Studio and env GOOS=android go build Picocrypt.go. If it takes too long, I'm going to abandon it, because honestly, no one encrypted important files on a phone. In terms of time and commitment, I set a max amount of time per day or per week that I'll work on my projects, because I would hate to abandon a project like Picocrypt which has received so much positive attention so far.

Libsodium was audited in 2017 and is one of the most popular cryptographic libraries, which means more people paying attention to the code.

Oh wow looks like my Googlefu is decaying... I searched up whether libsodium was audited and it somehow seems like I missed it smh... I'll take a look and consider it. But as of now, at least, I still think Monocypher is the simplest and has the least chance to go wrong. If people need speed, there's a fast mode that will use Go's standard golang.org/x/crypto/chacha20poly1305 which has about a 50% speed increase.

Moncypher only offers Argon2i, which is vulnerable to an attack unless you use more than 10 iterations.

I only use Monocypher for ChaCha20. I use Argon2id from Go's standard golang.org/x/crypto/argon2 package, so both side-channel and brute-forcing attacks are prevented.

it didn't make much sense to be working on two separate versions of the program at the same time

You're quite right about this one. That's why I haven't added a CLI yet, because ensuring both versions working in the same way would be somewhat difficult.

Anyways, there's a lot of things for me to consider and start working on now, so I better get going. Thank you for your suggestions.

[samuel-lucas6]

Yes, I show different error messages. The reason why I added a Reed-Solomon feature is because it's suitable for creating long-term archives that could be stored on a hard drive for a long time. Sometimes, data might corrupt so much that Reed-Solomon can't fix it, or the user might not have toggled the feature, so I would show a message saying that the data is corrupted, instead of assuming that the data is intact and that the password is incorrect.

Most programs just display one error saying either could have occurred in my experience, but I get why you'd like two separate error messages.

If I'm understanding you correctly, you're wondering how I prevent a hacker from adding/removing bytes when the chunk is padded? Well, while a hacker can add data to incomplete chunks as they wish, the Poly1305 won't pass. Either Poly1305 will catch the hacker, or the change in size would.

I'm afraid that's not what I meant again. Lets say you have a file that's 1 MiB and 1 byte. That extra 1 byte can't fit into the first 1 MiB chunk, so it will be padded out to another 1 MiB chunk. 1 byte is considerably smaller than 1 MiB, whereas 1 byte vs 16 KiB is less of a difference. Anything below 16 KiB is probably a bit small and anything above about 128 KiB is probably too large when it comes to chunking files.

Then what I meant by 'How are you handling files less than 1 MiB?' is are small files (< 1 MiB in size) being chunked to 1 MiB?

You've got a point. Thinking about this a little more, I think that is what I will do indeed. It will prevent chunk reordering, and not require me to go through the hassle of generating random nonces and then encrypting them at the end. Seems quite reasonable to me, thanks!

I'm glad you agree because that will be quite an improvement.

Sorry, my bad for forgetting that I'm using SHA3-512, not 256. So that would offer 256-bit security.

The Internals.md file says that you're using SHA3-256.

Oh wow looks like my Googlefu is decaying... I searched up whether libsodium was audited and it somehow seems like I missed it smh... I'll take a look and consider it. But as of now, at least, I still think Monocypher is the simplest and has the least chance to go wrong. If people need speed, there's a fast mode that will use Go's standard golang.org/x/crypto/chacha20poly1305 which has about a 50% speed increase.

To be clear, Monocypher is still a decent library, but I think you can make a strong argument for libsodium being a better library. However, Monocypher is smaller and was audited more recently. Go's crypto library is pretty good but isn't as fast or easy to use as libsodium.

I only use Monocypher for ChaCha20. I use Argon2id from Go's standard golang.org/x/crypto/argon2 package, so both side-channel and brute-forcing attacks are prevented.

That was a sensible decision, although in that case, why aren't you using XChaCha20-Poly1305 from Go's crypto library?

[HACKERALERT]

The Internals.md file says that you're using SHA3-256.

My bad, I've correct it.

To be clear, Monocypher is still a decent library, but I think you can make a strong argument for libsodium being a better library. However, Monocypher is smaller and was audited more recently. Go's crypto library is pretty good but isn't as fast or easy to use as libsodium.

I still don't quite see why I would use libsodium instead of Monocypher, because Monocypher is only 2k SLOC and easy to audit. Libsodium spans across many files, so if there was an issue, it would be detected quicker in Monocypher than Libsodium, because Monocypher implements only a few functions and does a good job of doing so. And Monocypher is also as simple as it gets: ciphertext, poly1305 := monocypher.Lock(plaintext,nonce,key). I don't see how libsodium can possibly get easier than that. But anyway, we all have different opinions, and since they're both audited, I don't see a reason why we can't choose either one.

That was a sensible decision, although in that case, why aren't you using XChaCha20-Poly1305 from Go's crypto library?

Because it's not audited :). It is faster than Monocypher, which is why I have a fast mode that uses Go's crypto library for better speeds. But the default is to use Monocypher because it provides better security, which is Picocrypt's ultimate goal.

[samuel-lucas6]

My bad, I've correct it.

By the way, why did you choose SHA3 over BLAKE2 or BLAKE3? They are both faster, and BLAKE2 offers equivalent security with a large security margin.

I still don't quite see why I would use libsodium instead of Monocypher, because Monocypher is only 2k SLOC and easy to audit. Libsodium spans across many files, so if there was an issue, it would be detected quicker in Monocypher than Libsodium, because Monocypher implements only a few functions and does a good job of doing so. And Monocypher is also as simple as it gets: ciphertext, poly1305 := monocypher.Lock(plaintext,nonce,key). I don't see how libsodium can possibly get easier than that. But anyway, we all have different opinions, and since they're both audited, I don't see a reason why we can't choose either one.

In your case, the only real reason to switch would probably be for better speed. They're both good libraries. Monocypher is much easier to audit, but libsodium has some functions that don't require a nonce to prevent nonce misuse. I'm not sure if Monocypher does because I haven't looked through all of the documentation.

Because it's not audited :). It is faster than Monocypher, which is why I have a fast mode that uses Go's crypto library for better speeds. But the default is to use Monocypher because it provides better security, which is Picocrypt's ultimate goal.

By that logic, shouldn't you be using Argon2i from Monocypher then? It's very unlikely Go's crypto library has a vulnerability with XChaCha20-Poly1305 at this point. You could get away with just using Go's crypto library to be honest.

[HACKERALERT]

By the way, why did you choose SHA3 over BLAKE2 or BLAKE3? They are both faster, and BLAKE2 offers equivalent security with a large security margin.

There's no need. I'm just hashing 32 bytes (the key), so there wouldn't be any significant difference, because hashing such a small amount of data is instant. All of the BLAKE series are optimized for speed, whereas SHA3 is optimized for security.

By that logic, shouldn't you be using Argon2i from Monocypher then? It's very unlikely Go's crypto library has a vulnerability with XChaCha20-Poly1305 at this point. You could get away with just using Go's crypto library to be honest.

Sure Argon2i from Monocypher is audited, but Argon2i is weak against GPU brute-forcing. Go's standard Argon2id would be more suitable since brute-force attacks are more relevant here than side-channel issues.

[samuel-lucas6]

There's no need. I'm just hashing 32 bytes (the key), so there wouldn't be any significant difference, because hashing such a small amount of data is instant. All of the BLAKE series are optimized for speed, whereas SHA3 is optimized for security.

Every little counts, and BLAKE2 offers the same security as SHA3. BLAKE even received more analysis than Keccak for the SHA3 competition. There aren't many cases where SHA3 is the best choice in my opinion.

Sure Argon2i from Monocypher is audited, but Argon2i is weak against GPU brute-forcing. Go's standard Argon2id would be more suitable since brute-force attacks are more relevant here than side-channel issues.

My point is that if you're saying Go's crypto library hasn't been audited, then why is it fine to use Argon2id from Go's crypto library but not XChaCha20-Poly1305? Unless it's considerably easier to use XChaCha20-Poly1305 in Monocypher than Go's crypto library, you may as well just use Go's implementation.

[HACKERALERT]

We all have different opinions, I guess that's all I can say. Something may seem better one way to you but seems better in another to me. I have chosen protocols and implementations that best suit my interests, and you have done the same with yours. I don't think there's a need to worry about these nit-picky details, because the difference that they make is miniscule.

[samuel-lucas6]

We all have different opinions, I guess that's all I can say. Something may seem better one way to you but seems better in another to me. I have chosen protocols and implementations that best suit my interests, and you have done the same with yours. I don't think there's a need to worry about these nit-picky details, because the difference that they make is miniscule.

Your algorithm choices are fine, but I'm pointing this stuff out because I'm not convinced by some of your reasoning. For instance, as I've said already, I don't think it's fair to claim that Monocypher is more secure than libsodium or that SHA3 is more secure than BLAKE2. From what I've read, the only real reason to use SHA3 would be because of the performance on hardware like ASICs or because it won the SHA3 competition. Then ditching Monocypher and just using Go's crypto library would remove a dependency and result in faster encryption.

Speed should be a priority. Speed is a factor that could determine whether or not someone uses your application or another tool. Assuming the same security, there's no downside to having better performance, so it doesn't make sense to brush off performance as unimportant.

[samuel-lucas6]

Another thing I forgot to mention is that I recommend you set up a security policy on GitHub because it's not clear how to report a vulnerability for Picocrypt at the moment.

Thank you for listing my username in the Thanks You's section by the way :)

[HACKERALERT]

Thanks for letting me know about Github Security! It will definitely be a good practice for security software.

[samuel-lucas6]

Thanks for letting me know about Github Security! It will definitely be a good practice for security software.

I noticed that you've added a security policy now, which is great. However, your website doesn't work on hardened Firefox - it's just a blank page.

So I just got in contact with Cure53 and they gave me an updated quote for an audit. Originally, an audit of Picocrypt would cost $8.5k, which is out of reach for a free project like this. Because the latest version uses Monocypher, a large chunk of stuff that needs to be audited was taken out, so the price was lowered a good amount. Now, the cost for an audit is a much more reasonable $5k, and within reach. So, donate on Open Collective and share Picocrypt with your friends. The more new users and donations Picocrypt gets, the sooner we'll be able to get it audited! Please take this seriously, because I can't afford to pay $5k for a project that I'm putting in many hours and not making any money from.

I also stumbled on this post on Reddit. Looks like I was right about the $5,000 figure. I really wouldn't call that 'within reach' though and seriously think you should reconsider your strategy for getting donations. It seems a bit misleading claiming that donations will go towards an audit when they likely won't because of the price tag. You don't need an audit for your program to be secure.

I just wanted to announce that I'll also be working on a project I named Solenoid, which will be a sister project to Picocrypt. Solenoid (despite being an actual word) stands for Solid Security for Paranoids, and its goal is to be the most secure encryption tool in existence. There will be no options, and it will be a little slow, which is why I decided to split it from Picocrypt. Also, Solenoid will be extremely tiny. Picocrypt is about 3MB on Windows, Solenoid is just 0.8MB. It's very much a work in progress, so there is no project page yet, but there will be soon.

Finally, I came across this post in your subreddit as well. Why are you now developing another tool that's a dumbed down version of Picocrypt? Why is having such a small file size so important? What does 'encrypted data can last centuries, if not indefinitely' mean? It all sounds like marketing language. The file size of an executable doesn't matter. How is it going to be more 'secure' than Picocrypt? If Picocrypt is indeed secure, then there's no need for another tool.

[HACKERALERT]

I noticed that you've added a security policy now, which is great. However, your website doesn't work on hardened Firefox - it's just a blank page.

That's strange. I'll look into it. How did you harden your firefox?

I also stumbled on this post on Reddit. Looks like I was right about the $5,000 figure. I really wouldn't call that 'within reach' though and seriously think you should reconsider your strategy for getting donations. It seems a bit misleading claiming that donations will go towards an audit when they likely won't because of the price tag. You don't need an audit for your program to be secure.

The lowest cost Cure53 offered was $3.75k, but I decided that $5k would be more in-depth and secure of an audit. Whether it works out or not should not be your concern. I know you may be more experienced than me in this sort of thing, but please take a look that these threads: 1, 2. I'm putting it out there because people would like to see it audited and a couple have donated before. If there is a demand, there will be a solution eventually. And I don't have to only rely on the community for donations -- there are many open-source funding programs like the OTF that is worth taking a look at.

Finally, I came across this post in your subreddit as well. Why are you now developing another tool that's a dumbed down version of Picocrypt? Why is having such a small file size so important? What does 'encrypted data can last centuries, if not indefinitely' mean? It all sounds like marketing language. The file size of an executable doesn't matter. How is it going to be more 'secure' than Picocrypt? If Picocrypt is indeed secure, then there's no need for another tool.

First of all, I don't make any money from this software and I develop it voluntarily, so it's not marketing. It makes me very sad when I carve many many hours out of my own free time on something that I'm providing for free and not making any money from, and then being seen as "marketing" my product, even though it's not commercial in any remote way.

The sister project, Solenoid, is not "dumbed down" in any way. Picocrypt is very secure, but I wanted a non-configurable "ad-hoc" software that would use the most secure standards available. Picocrypt uses ChaCha20 because it's secure and is quite fast. It's plenty secure by design, but, ChaCha20 is not the most secure cipher. The sister version will use the most secure block cipher, Serpent 256, in CTR mode, authenticated by HMAC-SHA3 using a subkey from the master key via HKDF-SHA3. Argon2 parameters will be double. These choices will be able to create encrypted data that will last 'encrypted data can last centuries, if not indefinitely'. AES is getting close to the edge of the cliff, with 10/14 of 256-bit AES broken (theoretically of course). One day, both ChaCha20 and Serpent will have more powerful attacks against them. But Serpent is more likely to remain secure than ChaCha20 because it was designed for security and has already lasted over 20 years without any major attacks. Most people will use Picocrypt, because it has more features and is more customizable than Solenoid. Solenoid, however, will be useful for encryption crypto private keys, whistleblowers that need maximum security, etc.

No offence, but I want you to consider that you and I are different again. We have different points of view and different preferences. And those differences are indirectly shown in the popularity of Picocrypt vs Kryptor. I'm not competing with you, but you should realize that a possible reason why Kryptor is not as popular as Picocrypt may just be because of your choices and view of things. I take things conservatively and create security software with secure standards that inspire trust. I'm not saying Kryptor is insecure (I know you are very skilled with security), but to people new to security, the standard SHA3 sounds more trustworthy than BLAKE2 which ultimately lost to Keccak. Consider being a little more open to others' opinions and not stick solely to your opinion of things, and Kryptor might be more popular :)

[samuel-lucas6]

That's strange. I'll look into it. How did you harden your firefox?

Following the steps on the PrivacyTools website.

The lowest cost Cure53 offered was $3.75k, but I decided that $5k would be more in-depth and secure of an audit. Whether it works out or not should not be your concern. I know you may be more experienced than me in this sort of thing, but please take a look that these threads: 1, 2. I'm putting it out there because people would like to see it audited and a couple have donated before. If there is a demand, there will be a solution eventually. And I don't have to only rely on the community for donations -- there are many open-source funding programs like the OTF that is worth taking a look at.

I'm not experienced either, but I now appreciate that there's far more to secure software than just having an audit. Yes, some people on Reddit want the program to be audited, but that's a biased sample, and many of those people are completely unaware of the cost of obtaining an audit. They also don't understand how difficult it is to receive funding. Some people seem to be under the impression that anybody can apply and miraculously get free money. That's not how it works.

KeePassXC is extremely popular despite it not being audited. They also make very valid points in their FAQ - flaws can still be missed in audits, and when you change the code, you can reintroduce vulnerabilities. If your code is well written, then you could end up spending $5,000 on an audit that uncovers nothing. Furthermore, there are plenty of people who will use your tool who don't even know what an audit is, meaning whether or not the tool has been audited doesn't matter to them. An audit is not some software requirement. You would be better off encouraging people to check over the source code.

Whether it works out or not is my concern because I don't want you to accidentally mislead people, and some of your comments about donations can be considered misleading. For instance, 'Please donate to Picocrypt on Open Collective to raise money for an upcoming audit from Cure53' suggests that an audit that costs $5,000 is definitely going to take place. How can you guarantee that? Unless Picocrypt becomes as popular as something like Wireguard, it seems unlikely that you will be able to fund an audit from donations alone. If you manage it, then great job proving me wrong, but all of my other points still apply. You shouldn't make claims that you cannot guarantee when accepting people's money.

As for open source funding, I've already explained that it's highly unlikely you will succeed there either since such organisations typically only give out grants to very popular projects like Tor. Tools like Kryptor and Picocrypt are not Tor or Wireguard. The reason Monocypher received funding is because it's a cryptographic library, meaning the code is very sensitive and going to be used in lots of projects.

First of all, I don't make any money from this software and I develop it voluntarily, so it's not marketing. It makes me very sad when I carve many many hours out of my own free time on something that I'm providing for free and not making any money from, and then being seen as "marketing" my product, even though it's not commercial in any remote way.

Statements like 'encrypted data can last centuries, if not indefinitely' can be considered misleading and remind me of weird marketing language used by VPN companies such as 'military grade encryption'. How do you know? You could be using the latest and greatest algorithm currently available, but a new attack could be found in the future. There's no need for such claims.

The sister project, Solenoid, is not "dumbed down" in any way.

'There will be no options, and it will be a little slow' and 'there's no splitting, drag and drop support, etc' suggests that it's lacking a lot of the functionality from Picocrypt.

Picocrypt uses ChaCha20 because it's secure and is quite fast. It's plenty secure by design, but, ChaCha20 is not the most secure cipher. The sister version will use the most secure block cipher, Serpent 256, in CTR mode, authenticated by HMAC-SHA3 using a subkey from the master key via HKDF-SHA3. Argon2 parameters will be double.

What is your basis for the claim that 'ChaCha20 is not the most secure cipher'? ChaCha20 is nowhere near broken, so there's nothing to worry about.

Then what is your basis for the claim that Serpent 256 is 'the most secure block cipher'? There might be some better attacks on AES, but they're still not computationally feasible, so there's nothing to worry about. If Serpent was generally considered as being better than AES, I think it would have been considerably more popular. It's slower than Rijndael and both offer essentially the same real world security. There's a reason AES is still popular.

AES is getting close to the edge of the cliff, with 10/14 of 256-bit AES broken (theoretically of course).

I really wouldn't describe it that way. AES is far from being practically broken. Although there's a related-key attack for 11/14 rounds, it's not practical and has been criticised.

One day, both ChaCha20 and Serpent will have more powerful attacks against them. But Serpent is more likely to remain secure than ChaCha20 because it was designed for security and has already lasted over 20 years without any major attacks.

ChaCha20 was also designed for security. Every cryptographic algorithm is designed for security. Serpent has 'lasted longer' because it's older. Neither are remotely broken. There are barely any attacks on ChaCha20 and none of them are 'major'.

No offence, but I want you to consider that you and I are different again. We have different points of view and different preferences. And those differences are indirectly shown in the popularity of Picocrypt vs Kryptor. I'm not competing with you, but you should realize that a possible reason why Kryptor is not as popular as Picocrypt may just be because of your choices and view of things. I take things conservatively and create security software with secure standards that inspire trust. I'm not saying Kryptor is insecure (I know you are very skilled with security), but to people new to security, the standard SHA3 sounds more trustworthy than BLAKE2 which ultimately lost to Keccak.

That's complete nonsense. Firstly, Keccak never went up against BLAKE2; it went up against BLAKE. BLAKE2 wasn't part of the SHA3 competition. Why did BLAKE lose? As explained by Zooko here, probably because BLAKE is more similar to SHA2 than Keccak, and Keccak has better hardware performance. It didn't 'lose' for security reasons.

Secondly, people new to security may not have even heard of SHA3 because it's not popular at all. BLAKE2 is far more popular than SHA3 and is even used in Argon2. There aren't many reasons to use SHA3 over SHA2 - SHA3 can actually be slower, and SHA2 isn't considered broken, although you do need to be careful when it comes to length extension attacks.

Finally, that has nothing to do with the popularity of Picocrypt or Kryptor. You have evidently advertised your tool far better than I have. When my program first came out, I made two posts on Reddit that received a fair amount of attention. However, when v3 came out, I wasn't allowed to post on Reddit because Kryptor is in beta. The fact that it's in beta because I may change a few things in the future probably puts a lot of people off, and now the switch to it being a CLI application puts some more people off too.

I have justified my design decisions on the website, whereas some of your justifications are questionable like this insistence that SHA3 is superior to BLAKE2. I also made the tool for myself primarily, much like how lots of Frank Denis' programs were made to solve problems he experienced. If people don't want to use it, it's not the end of the world.

Consider being a little more open to others' opinions and not stick solely to your opinion of things, and Kryptor might be more popular :)

Again, that has nothing to do with it. Moreover, I would argue that you're the one who should be more open to other people's opinions. You have received most of my feedback well, but you're very defensive about receiving donations for an audit/audits being crucial for security and have made various false claims related to the security of different algorithms. I have been trying to lay out the facts, but you appear to unfortunately be ignoring some of them.

I'm spending a lot of my time trying to provide constructive criticism, correct any inaccurate perceptions you may have, and clarify your rational. You're now refusing to accept certain facts and shifting the conversation to Kryptor vs Picocrypt for no appropriate reason. If this has just become a debate about who's program is better, then I will not be replying to any future messages on this issue. Similarly, if you aren't willing to improve your understanding of cryptography, then I will stop replying because it's just a waste of my time.

[HACKERALERT]

Following the steps on the PrivacyTools website.

So you have to disable WebGL..... which is why my site doesn't work because it uses WebGL.

I'm not experienced either, but I now appreciate that there's far more to secure software than just having an audit. Yes, some people on Reddit want the program to be audited, but that's a biased sample, and many of those people are completely unaware of the cost of obtaining an audit. They also don't understand how difficult it is to receive funding. Some people seem to be under the impression that anybody can apply and miraculously get free money. That's not how it works.

I agree with you about this. People think of an audit as a minor process that can be done easily without realizing that it costs thousands.

KeePassXC is extremely popular despite it not being audited. They also make very valid points in their FAQ - flaws can still be missed in audits, and when you change the code, you can reintroduce vulnerabilities. If your code is well written, then you could end up spending $5,000 on an audit that uncovers nothing. Furthermore, there are plenty of people who will use your tool who don't even know what an audit is, meaning whether or not the tool has been audited doesn't matter to them. An audit is not some software requirement. You would be better off encouraging people to check over the source code.

The points are valid, but an audit would squash 99% of issues, and since I would be the one to fix them, I would gain experience and it would decrease my chances of creating more security bugs in the future. The code for encryption is already set in stone and I'm not changing it, so even if I do make changes, it likely won't affect core encryption in any way.

Whether it works out or not is my concern because I don't want you to accidentally mislead people, and some of your comments about donations can be considered misleading. For instance, 'Please donate to Picocrypt on Open Collective to raise money for an upcoming audit from Cure53'

Alright, thanks for pointing this out. I will change it to 'Please donate to Picocrypt on Open Collective to raise money for a potential audit from Cure53', which will be more conservative.

As for open source funding, I've already explained that it's highly unlikely you will succeed there either since such organisations typically only give out grants to very popular projects like Tor. Tools like Kryptor and Picocrypt are not Tor or Wireguard. The reason Monocypher received funding is because it's a cryptographic library, meaning the code is very sensitive and going to be used in lots of projects.

But giving it a go is still a good idea. Just because the chances are unlikely doesn't mean you should give up. There's nothing to lose other than a couple minutes to fill out a form or send an application. Why not be optimistic and give it a try?

Statements like 'encrypted data can last centuries, if not indefinitely' can be considered misleading and remind me of weird marketing language used by VPN companies such as 'military grade encryption'. How do you know? You could be using the latest and greatest algorithm currently available, but a new attack could be found in the future. There's no need for such claims.

No one knows, which is why I put 'encrypted data can last centuries, if not indefinitely'. I did not say it will last indefinitely nor did I say it will last centuries. I'm just saying that Serpent is likely to outlast any cipher created so far and will likely last for a very long time. It was designed by Ross Anderson, Eli Biham, and Lars Knudsen, two of which were the most famous "cryptanalyzers" in their time. From their homepage:

We designed Serpent to provide users with the highest practical level of assurance that no shortcut attack will be found. To achieve this, we limited ourselves to well understood mechanisms, so that we could rely on the existing experience of block cipher cryptanalysis. We also used twice as many rounds as are sufficient to block all currently known shortcut attacks. We believed this to be prudent practice for a cipher that might have a service life of a century or more.

And said by Schneier:

And its design team includes two of the most impressive names in cryptanalysis this decade—Eli Biham and Lars Knudsen.

Serpent was designed with pretty much only one thing in mind -- security. And since the AES competition has done a lot of cryptanalysis on Serpent, and it is over two decades old with no issues, it's safe to say that it will last many more.

'There will be no options, and it will be a little slow' and 'there's no splitting, drag and drop support, etc' suggests that it's lacking a lot of the functionality from Picocrypt.

So? Solenoid an "ad-hoc" project originally for personal use. But I decided to make it public since it would be a good addition to Picocrypt. Solenoid is not a separate piece of software. It's an extension to Picocrypt that offers extremely high levels of security.

What is your basis for the claim that 'ChaCha20 is not the most secure cipher'? ChaCha20 is nowhere near broken, so there's nothing to worry about.

ChaCha20 is nowhere close to the security of Serpent. ChaCha20 (theoretically of course) has 7/20 rounds broken, leaving 13 rounds of security. Serpent as 12/32 rounds broken, leaving 20 rounds of security. Serpent may be slow, but it is designed conservatively for the best security, so while I cannot say for sure that Serpent is more secure, I can so with a high level of confidence.

It's slower than Rijndael

That's exactly why Rijndael won -- because it's faster, not more secure. And honestly, isn't the point of having an international "competition" to find a newer and safer cipher to DES supposed to hold security as the highest standard? Speed and security aren't friends and very unlikely for a cipher to have high security without a measurable decrease in speed.

I really wouldn't describe it that way. AES is far from being practically broken. Although there's a related-key attack for 11/14 rounds, it's not practical and has been criticised.

Yes, I know. But, cryptanalysis has increased steadily over the years, and with quantum computing on the rise, AES is no longer as secure as it was before. Since quantum computing effectively halves the security, AES-256 would be relatable to the security of AES-128 with 11/14 rounds broken. That's not looking great. We need to look toward the future, and not glue our eyes to the present day. AES and ChaCha20 (and Serpent) will be broken one day, but Serpent will likely survive the longest.

ChaCha20 was also designed for security. Every cryptographic algorithm is designed for security. Serpent has 'lasted longer' because it's older. Neither are remotely broken. There are barely any attacks on ChaCha20 and none of them are 'major'.

Of course, cryptographic algorithms are designed for security. But ChaCha20 is (imo) 80% security and 20% performance, whereas Serpent is 95% security and 5% performance. Indeed, ChaCha20 is very secure, which is why I chose it for use in Picocrypt in the first place. I trust ChaCha20 and I'm not trying to stab at it.

it went up against BLAKE

My bad, I knew that but I'm using to typing BLAKE2 so much that I did it without noticing.

Why did BLAKE lose? As explained by Zooko here, probably because BLAKE is more similar to SHA2 than Keccak, and Keccak has better hardware performance. It didn't 'lose' for security reasons.

Zooko is obviously biased (not in a bad way though), being one of the creators. Consider this... BLAKE had 14 rounds. It was reduced to 10 in BLAKE2. And it was reduced again to 7, in favour of performance. I don't see how they are holding security in high regard. While SHA3 used many more rounds than necessary and had a sponge construction that has only been proven more secure as time went on, the BLAKE series are consistently being cut short in rounds (and therefore security) so it can achieve better performance. As I said above, security and speed were never friends. Sure, you can find something with a good compromise of both, but if you want security, SHA3 is the way to go. The NIST wouldn't standardize something unless there's a good reason for it.

Secondly, people new to security may not have even heard of SHA3 because it's not popular at all. BLAKE2 is far more popular than SHA3 and is even used in Argon2.

I highly doubt that. If they've heard of SHA, then they will likely know SHA3, which after all, is the standard. I'm not saying BLAKE2 is unpopular, but I (along with many others), would prefer to go the conservative path and use something that is standard and secure.

There aren't many reasons to use SHA3 over SHA2 - SHA3 can actually be slower, and SHA2 isn't considered broken, although you do need to be careful when it comes to length extension attacks.

There may not be now, but there will be some day. The NIST started the SHA3 process for a reason.

Finally, that has nothing to do with the popularity of Picocrypt or Kryptor. You have evidently advertised your tool far better than I have.

Yes, I will admit that I have put a lot of time into the docs and replying to Reddit threads etc.

When my program first came out, I made two posts on Reddit that received a fair amount of attention.

I only made one more than you. Two of them had less than 50 upvotes combined. And the one in r/privacytools.io had more than 500. Not meaning anything here, just stating some statistics.

I have justified my design decisions on the website, whereas some of your justifications are questionable like this insistence that SHA3 is superior to BLAKE2.

And where have I stated BLAKE2 is better than SHA3 on my homepage or internals? I don't see "BLAKE" anywhere. And in this thread, I'm only stating that the security of SHA3 is likely better than BLAKE2. I know BLAKE2 is faster and (maybe) more popular, but in no way have I criticized BLAKE2 in any other way. In fact, I didn't say at all that BLAKE2 is insecure. I just said that SHA3 is more secure, by design, and standardization. And that there were more people on the Keccak Team, including Joan Daemen from AES.

I also made the tool for myself primarily

Same. But I decided to publish it so other people can benefit from its simplicity.

but you're very defensive about receiving donations for an audit/audits being crucial for security and have made various false claims related to the security of different algorithms.

I'm defending the audit because it is crucial to security. And it's also critical to trust and confidence. How am I making "false" claims? Sure, they may be a little opinionated, but they are backed by facts and my research. I was not born biased toward Serpent or SHA3. I've done my research and chose what I did because they reflect my core values -- security and reliability. And let's just pretend I was making false claims. Then, you can't say BLAKE2 is more secure than SHA3. So, it would only be logical for them to be of the same security. So, both would be fine and I would choose SHA3. You can't say BLAKE2 is better, just like I can't say how SHA3 is better.

I have been trying to lay out the facts, but you appear to unfortunately be ignoring some of them.

I truly do appreciate it, why is why I listed your name on my homepage and why I will keep it forever. If I didn't respect your comments, then I would have not put your name there in the first. You have many valid points which I respect and will follow, but if I followed everything you suggested, Picocrypt would no longer be mine -- it would be yours. And if you feel like better algorithms can be chosen, you can fork my repo and make your proposed changes. You would think your fork is better than mine, and I would think mine is better than yours. But that's not important in any way. What's important is that I provide the public with a tool using standardized protocols that can be trusted with confidence.

I'm spending a lot of my time trying to provide constructive criticism, correct any inaccurate perceptions you may have, and clarify your rational.

Again, I thank you for your time and feedback, and you have many valid points. However, I don't think it's fair to say that choosing SHA3 over BLAKE2 is an "inaccurate perception". As I've said before, the NIST is not stupid and they choose Keccak because it uses a sponge construction which has only been proven more and more secure. What's "inaccurate" about being conservative and choosing the standards?

You're now refusing to accept certain facts and shifting the conversation to Kryptor vs Picocrypt for no appropriate reason. If this has just become a debate about who's program is better, then I will not be replying to any future messages on this issue.

Of course, I am. It's impossible for everybody to agree on something. And often, there's no wrong or right, only preference. I am not trying to hurt Kryptor in any way. I just wanted to let you know that your choices affect your software. For example, as you stated yourself, going from GUI to CLI reduced Kryptor's user base by a little. And for me, going GUI-oriented also caused Picocrypt to lose some CLI fans, although not as many because GUI is preferred in these days. I just want you to realize that you should stop attacking my choices because my choices are what make my software mine and that if we all think one way about something, that's not good. At least I didn't choose PBKDF2 as a KDF, right?

Similarly, if you aren't willing to improve your understanding of cryptography, then I will stop replying because it's just a waste of my time.

Of course, I am willing to improve. But convincing me that a non-standard hash is better than a standard and designed-for-security hash function is not going to help me in any positive way.

Can we stop arguing about this, since we are both biased? How about we ask the community what they feel about this thread...

[samuel-lucas6]

Look, this is a mess. Some of your rational is flawed, and you seem to have fallen prey to confirmation bias. I had a similar idea of security and believed that 'bigger is better', so I get it. However, you need to come around to a more realistic viewpoint.

This is my last attempt at providing the facts. If you can't be swayed, then I vote that Picocrypt shouldn't be listed because of this audit fiasco and all of your wild claims related to security. You have been informed, and yet you still refuse to accept the facts and tone down your over the top statements. That's problematic.

The points are valid, but an audit would squash 99% of issues, and since I would be the one to fix them, I would gain experience and it would decrease my chances of creating more security bugs in the future. The code for encryption is already set in stone and I'm not changing it, so even if I do make changes, it likely won't affect core encryption in any way.

$5,000 is a lot of money to be paying for someone to read through your code and create a PDF report. If you know what you're looking for, then you should be able to identify the most common mistakes yourself. Then encouraging other people to look over your source code may also lead to people finding vulnerabilities.

Yes, you would gain experience fixing vulnerabilities if there were any, but there's no guarantee that an audit would squash 99% of issues. You've just plucked that figure out of thin air. That's another example of a claim that you shouldn't be making.

Alright, thanks for pointing this out. I will change it to 'Please donate to Picocrypt on Open Collective to raise money for a potential audit from Cure53', which will be more conservative.

That's good.

But giving it a go is still a good idea. Just because the chances are unlikely doesn't mean you should give up. There's nothing to lose other than a couple minutes to fill out a form or send an application. Why not be optimistic and give it a try?

Go ahead, but it takes more than a couple of minutes to fill out the form properly, and don't get your hopes up. There's optimism, and there's realism.

No one knows, which is why I put 'encrypted data can last centuries, if not indefinitely'. I did not say it will last indefinitely nor did I say it will last centuries. I'm just saying that Serpent is likely to outlast any cipher created so far and will likely last for a very long time. It was designed by Ross Anderson, Eli Biham, and Lars Knudsen, two of which were the most famous "cryptanalyzers" in their time. From their homepage:

'Can last centuries' sounds similar enough to 'will last centuries' to me. Regardless, that sort of comment isn't needed.

There seems to be some confirmation bias going on here. I'll admit that I don't know much about Serpent because I've barely heard anyone talk about. It appears to be a solid algorithm, but your claims about it being the best are up for debate. I really have no idea where you have got this idea from. Serpent won't outlast the one-time pad.

Serpent was designed with pretty much only one thing in mind -- security. And since the AES competition has done a lot of cryptanalysis on Serpent, and it is over two decades old with no issues, it's safe to say that it will last many more.

I'm sure it will because it's definitely not broken.

So? Solenoid an "ad-hoc" project originally for personal use. But I decided to make it public since it would be a good addition to Picocrypt. Solenoid is not a separate piece of software. It's an extension to Picocrypt that offers extremely high levels of security.

So it's a simplified ('dumbed down') version of Picocrypt. How is it not a separate program? Whatever, it doesn't matter. The reason I brought it up was because of your notion of 'the most secure encryption tool in existence'. Again, another unnecessary, bold claim.

ChaCha20 is nowhere close to the security of Serpent. ChaCha20 (theoretically of course) has 7/20 rounds broken, leaving 13 rounds of security. Serpent as 12/32 rounds broken, leaving 20 rounds of security. Serpent may be slow, but it is designed conservatively for the best security, so while I cannot say for sure that Serpent is more secure, I can so with a high level of confidence.

Where has this idea come from? 7/20 rounds have not been 'broken'. The complexity for ChaCha7 is 2^237.7. I suggest you read some of that paper I just linked to clear up what 'broken' actually means. ChaCha20 is very conservative as well.

That's exactly why Rijndael won -- because it's faster, not more secure. And honestly, isn't the point of having an international "competition" to find a newer and safer cipher to DES supposed to hold security as the highest standard? Speed and security aren't friends and very unlikely for a cipher to have high security without a measurable decrease in speed.

Speed and security can be friends. There's such a thing as over the top security. AES and ChaCha20 both provide high security and speed.

Yes, I know. But, cryptanalysis has increased steadily over the years, and with quantum computing on the rise, AES is no longer as secure as it was before. Since quantum computing effectively halves the security, AES-256 would be relatable to the security of AES-128 with 11/14 rounds broken. That's not looking great. We need to look toward the future, and not glue our eyes to the present day. AES and ChaCha20 (and Serpent) will be broken one day, but Serpent will likely survive the longest.

Nobody truly understands the capabilities of quantum computers, and they are not 'on the rise' just yet. The '11/14 rounds broken' isn't the best way of putting it either. That attack results in a speed increase compared to a full bruteforce, but that doesn't mean it's necessarily computationally feasible.

Of course, cryptographic algorithms are designed for security. But ChaCha20 is (imo) 80% security and 20% performance, whereas Serpent is 95% security and 5% performance. Indeed, ChaCha20 is very secure, which is why I chose it for use in Picocrypt in the first place. I trust ChaCha20 and I'm not trying to stab at it.

More figures plucked from thin air. If you believe ChaCha20 is 'very secure', then why are you claiming that 'ChaCha20 is nowhere close to the security of Serpent'? If you trust ChaCha20, then why are you so against it? Some of these statements are just all over the place.

Zooko is obviously biased (not in a bad way though), being one of the creators. Consider this... BLAKE had 14 rounds. It was reduced to 10 in BLAKE2. And it was reduced again to 7, in favour of performance. I don't see how they are holding security in high regard. While SHA3 used many more rounds than necessary and had a sponge construction that has only been proven more secure as time went on, the BLAKE series are consistently being cut short in rounds (and therefore security) so it can achieve better performance. As I said above, security and speed were never friends. Sure, you can find something with a good compromise of both, but if you want security, SHA3 is the way to go. The NIST wouldn't standardize something unless there's a good reason for it.

Because there's a big enough security margin to lower the number of rounds, although I do think BLAKE3 went a bit far.

You're not listening again! BLAKE2 offers the same level of security as SHA3. This 'if you want security' thinking is nonsense. Both have high security margins. Why does it being a standard matter so much? Applying that logic means that you should be using AES, not ChaCha20 or Serpent. Why are you making exceptions for the encryption algorithm but not for the hash function? These are the sort of inconsistencies I'm trying to correct.

I highly doubt that. If they've heard of SHA, then they will likely know SHA3, which after all, is the standard. I'm not saying BLAKE2 is unpopular, but I (along with many others), would prefer to go the conservative path and use something that is standard and secure.

Based on your comments, BLAKE2 is more conservative, so what you're saying doesn't make any sense. BLAKE2 is also secure. Then you're happy to use ChaCha20, which is not a NIST standard. Your reasoning is inconsistent.

There may not be now, but there will be some day. The NIST started the SHA3 process for a reason.

Yes, they did, and they succeeded in the sense that the competition resulted in Keccak, BLAKE2, and now BLAKE3. However, since SHA2 isn't broken, it's fine to still use SHA2.

And where have I stated BLAKE2 is better than SHA3 on my homepage or internals? I don't see "BLAKE" anywhere. And in this thread, I'm only stating that the security of SHA3 is likely better than BLAKE2. I know BLAKE2 is faster and (maybe) more popular, but in no way have I criticized BLAKE2 in any other way. In fact, I didn't say at all that BLAKE2 is insecure. I just said that SHA3 is more secure, by design, and standardization. And that there were more people on the Keccak Team, including Joan Daemen from AES.

I'm referring to this GitHub issue. BLAKE2 and SHA2 are definitely more popular than SHA3. You keep saying that SHA3 is more secure, but they offer the same level of security. They both have strengths and weaknesses, and you're largely ignoring the strengths of BLAKE2.

I'm defending the audit because it is crucial to security. And it's also critical to trust and confidence. How am I making "false" claims? Sure, they may be a little opinionated, but they are backed by facts and my research. I was not born biased toward Serpent or SHA3. I've done my research and chose what I did because they reflect my core values -- security and reliability. And let's just pretend I was making false claims. Then, you can't say BLAKE2 is more secure than SHA3. So, it would only be logical for them to be of the same security. So, both would be fine and I would choose SHA3. You can't say BLAKE2 is better, just like I can't say how SHA3 is better.

It's not 'crucial' to security. Software doesn't need to be audited to be secure. The libsodium library was only audited in 2017, and yet it was popular before then and the audit only really uncovered one minor issue.

You are clearly biased towards Serpent and SHA3, and you have made false claims. Both hash functions are fine, but I can argue that BLAKE2 is a better choice because it's faster and offers the same level of security. You can argue SHA3 is better because it's faster on hardware like ASICs and won the SHA3 competition.

You have many valid points which I respect and will follow, but if I followed everything you suggested, Picocrypt would no longer be mine -- it would be yours. And if you feel like better algorithms can be chosen, you can fork my repo and make your proposed changes. You would think your fork is better than mine, and I would think mine is better than yours. But that's not important in any way. What's important is that I provide the public with a tool using standardized protocols that can be trusted with confidence.

I appreciate that you want to choose your own algorithms, but you should be able to accept the facts. I have said several times that SHA3 is fine, but it's slower than BLAKE2 in software. You don't seem to care about speed at all based on your comments, so that's even more reason to keep using SHA3.

Again, I thank you for your time and feedback, and you have many valid points. However, I don't think it's fair to say that choosing SHA3 over BLAKE2 is an "inaccurate perception". As I've said before, the NIST is not stupid and they choose Keccak because it uses a sponge construction which has only been proven more and more secure. What's "inaccurate" about being conservative and choosing the standards?

'Inaccurate perceptions' refers to strange claims about audits being necessary for security, SHA3 being more secure than BLAKE2, Serpent being the most secure cipher ever made, encrypted data lasting centuries, and so on. Please just stop and think. Do more research, fact check what I'm saying, and stop making inaccurate claims.

I just want you to realize that you should stop attacking my choices because my choices are what make my software mine and that if we all think one way about something, that's not good.

I'm criticising some of your choices because they can be criticised. You made good decisions on the whole, but your disregard for speed is concerning and deserves criticism.

Of course, I am willing to improve. But convincing me that a non-standard hash is better than a standard and designed-for-security hash function is not going to help me in any positive way.

You are ignoring certain facts, being overly paranoid, and have a 'bigger is better'/'standardised is the best' mentality. Please stop saying things like 'designed for security'. Cryptography is about security. If it's not secure, then it's not a good cryptographic algorithm. If it's not a good cryptographic algorithm, then it won't get used. Why is BLAKE2 being used? Because it's a good algorithm. Why did SHA3 win the SHA3 competition? Because it's a good algorithm. Does that guarantee that it's the best algorithm? No. There are plenty of brilliant actors who receive barely any awards.

Can we stop arguing about this, since we are both biased? How about we ask the community what they feel about this thread...

Everybody is biased. I would love to stop arguing about this because I'm throwing my time down the drain since you're ignoring most of what I'm saying. I won't be replying again, so there's no need to reply to this message. Please just think about what I'm saying. Good luck with your program.

[lynn-stephenson]

Zooko is obviously biased (not in a bad way though), being one of the creators. Consider this... BLAKE had 14 rounds. It was reduced to 10 in BLAKE2. And it was reduced again to 7, in favour of performance. I don't see how they are holding security in high regard. While SHA3 used many more rounds than necessary and had a sponge construction that has only been proven more secure as time went on, the BLAKE series are consistently being cut short in rounds (and therefore security) so it can achieve better performance. As I said above, security and speed were never friends. Sure, you can find something with a good compromise of both, but if you want security, SHA3 is the way to go. The NIST wouldn't standardize something unless there's a good reason for it.

SHA2, SHA3, and BLAKE2 are secure for real world applications. In terms of security, there is no significant difference, just choose one and stick with it. However, BLAKE2 is quite a bit faster, which may give an edge on hashing large amounts of contents. BLAKE3 might be pushing the boundaries, but I don't know for sure. I would have to conduct more research on it.

ChaCha20 is nowhere close to the security of Serpent. ChaCha20 (theoretically of course) has 7/20 rounds broken, leaving 13 rounds of security. Serpent as 12/32 rounds broken, leaving 20 rounds of security. Serpent may be slow, but it is designed conservatively for the best security, so while I cannot say for sure that Serpent is more secure, I can so with a high level of confidence.

That doesn't translate to real world applications, though. Cracking further each round is typically considerably harder than the previous attempt. Anyway, those are considered academic breaks. It will be a long time before ChaCha12 is practically broken. There are many other aspects to consider other than round count.

Both Salsa and ChaCha were designed to be much easier to implement in a safe fashion naïvely (unlike AES, thanks to SBoxes), all while providing a cipher with a large security margin, and offering good performance. It is a good cipher because of how well balanced it is.

But from a real world perspective, Serpent is not any more secure than ChaCha is. Choosing some obscure implementation of Serpent (which probably wasn't audited, and probably isn't constant-time) seems like a much bigger risk than opting for a Salsa/ChaCha variant.

Most of the time it has far less to do with the cryptographic algorithm itself, and far more to do with specific implementations.

Because Serpent wasn't well balanced, that's why it did not receive widespread adoption.

[HACKERALERT]

Hi @lynn-stephenson, thank you for expressing your opinion, I appreciate it! It's great to have someone else's opinion.

SHA2, SHA3, and BLAKE2 are secure for real world applications. In terms of security, there is no significant difference, just choose one and stick with it. However, BLAKE2 is quite a bit faster, which may give an edge on hashing large amounts of contents. BLAKE3 might be pushing the boundaries, but I don't know for sure. I would have to conduct more research on it.

Yes, I agree that they are all good for real world applications. And alright, BLAKE2 and SHA3 are similar in security. But I personally prefer a sponge construction as it has no known weaknesses yet, whereas BLAKE2 is based off of SHA2, which does have some weakness. But in real world scenarios, I agree that they won't have a significant difference. BLAKE2 is quite a bit faster, although that is not useful in my scenario, where I use SHA3 only to hash 32 bytes of data (the master key) for the whole encryption process. SHA3 isn't used as an HMAC or something like that, so the difference between BLAKE2 and SHA3 here would be extremely minuscule, probably only by a couple milliseconds.

Anyway, those are considered academic breaks.... There are many other aspects to consider other than round count.

Right. ChaCha's simple construction (and therefore ease of implementation) is why I chose it.

But from a real world perspective, Serpent is not any more secure than ChaCha is. Choosing some obscure implementation of Serpent (which probably wasn't audited, and probably isn't constant-time) seems like a much bigger risk than opting for a Salsa/ChaCha variant.

Agreed. Comparing an unbroken cipher with another unbroken cipher in the real world is likely not going to wield anything. But.... ChaCha was created by one person - DJB. And I'm not saying he's not good or anything like that, because he is a distinguished and honorable figure that has accomplished more than most will ever be able to. But Serpent was created by three people, two of which are arguable the most well-known for cryptanalysis in their time. And Serpent was designed using only thoroughly-studied primitives, and had double the necessary rounds. Schneier (https://www.schneier.com/academic/archives/1998/12/the_twofish_encrypti.html):

Serpent. It’s pretty hard to find anything wrong with this submission. It’s not the fastest, but that’s only because of its overly conservative design. It works on low-memory smart cards and 32-bit CPUs. And its design team includes two of the most impressive names in cryptanalysis this decade—Eli Biham and Lars Knudsen.

So my choice of Serpent is justified. In fact, Serpent is a relatively easy cipher to implement - most of it is just hard coded SBoxes. And since I intend on cascading it with ChaCha20, no security is lost if Serpent is broken or I use a faulty implementation.

But I will admit that finding a good implementation might be difficult.

Because Serpent wasn't well balanced, that's why it did not receive widespread adoption.

Yes, Serpent may not be the best balance, since Schneier did say "overly conservative". But people care about speed more than anything these days.... Why do we buy new phones? Why do we buy new laptops? Why do we buy new PCs? Why do we trash our usable old electronics to buy newer ones, when continuing to use an older but functional device will save thousands of litres of water and prevent hundreds of cubic meters of CO2 from being produced? Why do we mine coal and oil just because it's cheap and fast, when it pollutes the atmosphere? Why do fast-growing chickens exist, when they cause children to prematurely grow up? Why do we buy faster Internet even though it's overpriced? Why do (most) of us use Windows just because it's faster to learn and easier use than Linux? Why do people stay up at 2AM to check crypto prices? Because it's "fast money" as crypto nerds who don't even understand what a market cap is say. And for Linux users, speed is probably one factor of why you're a Linux user (privacy of course is a significant one). Why do we give away our privacy because it's slower to do something privately (VPNs are slower than no VPN, same with Tor)? Why do we pay thousands for new RTXs when they're out of stock, minerals are out of stock, and the demand and electricity toll is hurting our planet? Why did Apple slow down older iPhones on purpose (and get in a lawsuit)? Why do people speed on highways when driving at the limit is safer? Why do we buy SSDs when it's basically impossible to securely shred a file on them? Why do we use USB-C and Thunderbolt when they can be exploited to do a cold-boot attack? Why do people use Windows365 when it's hosted by a privacy-invading company on their own hardware and network? I can go on and on and on and on....

The point I'm ultimately trying to get at here is that speed is something that's overvalued in my honest opinion. Fast is great, but when fast undermines privacy and security, I don't like that. And I'm not saying that AES or ChaCha20 are bad because they're fast... They're pretty solid in my opinion. However, while ChaCha20 is the default encryption algorithm in Picocrypt, I'm adding the option to cascade Serpent with ChaCha20 for better security, for the truly paranoid.

My choice of primitives should be my decision. Nobody has the right to judge me because I like black chocolate over white (You're not judging me or anything, just putting out a point 👍 ). No one has the write to say I'm a virus just because I'm Chinese (again, I know you're not 👍 ). As long as I don't choose something insecure, there's no reason to argue over these minuscule differences. I'm just telling you my honest opinion, please don't take this as a "You don't agree with me, so I don't like you" thing. We each have our preferences and we each have a right to prefer one over the other. I value your opinion and I sincerely thank you for your inquiries and completely valid points. And I thank you greatly for your time.

If you have feedback, I am open to listening 💯 .

Sorry if you can sense some anger in me right now, it's not directed toward you. I'm just giving some honest feelings.

Thanks for your feedback again, and I wish you a great day 😄 (I mean it, I'm not just being polite).

[lynn-stephenson]

Things have gotten quite off topic, so I'll get things back on track. As far as I've reviewed so far, there is no immediate major problems with your program after taking a quick look. I don't know Go, but it seems alright.

The construction of cryptographic primitives seem fine, and each use reasonable parameters. However I should set up a development environment to take a closer look at your application.

I did notice your code is a little messy. Could you try splitting it up in different files in a more organized manner? Do you have any unit tests?

[HACKERALERT]

Great respect and thanks for helping me keep things on track 🙏 .

Great to get another pair of eyes on my code. I wrote the cryptographic components with lots of caution and testing, so there shouldn't be any major issues, as you have just noticed. Plenty of planning and analysis went in. Partitioning oracle attacks are something new that FiloSotille's age had a recent patch for, and I'm still working out the most effective patch for Picocrypt.

My code is currently a little messy, I know :). v1.12 was the last release in Python and it was stable and the code was clean. Then I decided to port 1.5k lines of idiomatic Python to idiomatic Go, and so there was a lot of experimenting and problem solving. I released v1.13 as the first release in Go, so the code could use a janitor. As v1.14 and v1.15 come outt, the code will stabilize and be cleaned up. As for splitting into multiple files, I did consider this, but one of the goals of Picocrypt is to be simple. Not just to use, but also to audit. A single source file with <2k lines of code seems welcoming for me than 5 different source files with imports and folders everywhere. May I get your opinion on this?

Also, what do you mean by unit tests? In terms of tests, CodeQL scans for issues every time I push to the sources file.

Thank you!

[samuel-lucas6]

I'm trying to create simple encryption software to make the Internet a safer place, but Samuel has been slowing me down, and it's not just me that disagrees with him (there are people on Reddit as well). The fact that he deletes his Crypto.StackExchange account immediately after asking a question says something about his character. I'll say no more, as I want to remain polite and civil.

I really don't understand what you're trying to achieve convoluting the conversation with more off-topic discussion. I'm sorry about our argument(s). We are both at fault there, and things should have been handled better, but we both got frustrated. There's no need to make a false claim about me and then insult my character.

I have never had a Cryptography Stack Exchange account. I have always used guest accounts, which cannot be deleted. Once you close the browser window, you can't edit anything, reply, etc. Why do I use guest accounts? Because a) I don't intend to ask many questions, b) I don't want to share my personal information and create another unnecessary account for something, and c) I don't want to be linked back to the questions I've asked. That's the entire point of allowing guests to ask questions.

I believe I've made at most five posts on the entire Stack Exchange network, so I have no idea what sort of background research you've been doing on me. Please just move on. You've been given some valuable feedback like don't use random nonces, split the code into more subroutines, and don't bother hashing the key, so that gives you plenty of things to work on. Finally, never write 'I want to remain polite and civil' after insulting someone.

[samuel-lucas6]

@HACKERALERT This is getting ridiculous. What on earth is this? You really aren't doing yourself any favours here.

I don't want to spam this issue with drama, so I'll just reply by saying that xkcd386 is missing out a key detail. Instead of explaining a concept that I didn't understand, he resorted to insulting me via several PMs. I then stupidly created a question to establish the answer with his username as part of my name (Questioning xkcd386) to get back at him. I later apologised to him through the mod but couldn't delete the question because it was a guest account. He never apologised for insulting me and then voiced this 'inability to heed other people's responses' nonsense. I deleted Reddit because it's a time wasting platform, and I want to avoid getting into more confrontations like that one and acting rashly, which is exactly why I stay away from social media besides now having GitHub. Even here, it seems I can't avoid getting into a confrontation.

[HACKERALERT]

Hi @samuel-lucas6 I greatly thank you for coming back even though you say you're throwing your time down the drain. Thanks for toning it down, I will as well.

I'm sorry about our argument(s)

I am too. Sorry.

We are both at fault there, and things should have been handled better, but we both got frustrated.

I think we both agree on this. I apologize for saying SHA3 is more secure than BLAKE2. I'm happy to say now that they have similar levels of security.

I have never had a Cryptography Stack Exchange account. I have always used guest accounts, which cannot be deleted. Once you close the browser window, you can't edit anything, reply, etc. Why do I use guest accounts? Because a) I don't intend to ask many questions, b) I don't want to share my personal information and create another unnecessary account for something, and c) I don't want to be linked back to the questions I've asked. That's the entire point of allowing guests to ask questions.

Thank you for your explanation, I respect your decisions and I've edited my remark off from my previous post. I just have one question: Why don't you want to be linked back to the questions you asked?

You've been given some valuable feedback like don't use random nonces, split the code into more subroutines, and don't bother hashing the key, so that gives you plenty of things to work on.

Thank you. But for the random nonces, here's what Monocypher's author says (https://monocypher.org/manual/aead):

The easiest (and recommended) way to generate this nonce is to select it at random.

Other than that, I agree with your valid points and I will incorporate them. I've never removed your name as a thanks from Picocrypt's homepage for these points.

Thank you for explaining the xkcd__386 misunderstanding. You have clarified the situation, I understand, and I have removed those screenshots, etc. from the Reddit post.

I stay away from social media

Same. Reddit, Discord, and GH are the only way to reach me other than email.

I know you're a good person at heart, and I'm sorry for the confrontations that constantly hit you. I'm here not to attack you deliberately.

And I didn't hit thumbs down on your request to remove GPG because I don't like you. If someone else said what you did, I would as well. Ideally, GPG would be moved to worth mentioning, imo.

Hopefully this clears up some of the beef between us. We've both made mistakes, but let's correct them and continue on productively. We have a common cause and common skill.

Have a great day!

[samuel-lucas6]

I'm afraid I can't take anything you say seriously after reading things like this:

You've insulted me multiple times and are now trying to downplay it as if nothing happened. Furthermore, that's not what I said at all. Then you had no context for the xkcd situation but believed his side of the story. Lastly, you've joked about me being crazy for wanting GPG to be delisted without providing a reason for GPG to remain listed.

In response to xkcd's new comment, I don't understand cryptography in its entirety and can't read cryptography papers well. Neither of those things are required to write cryptographic software. You just need to be willing to research and learn the necessary information. If the books you have access to don't discuss oracles and no explanation of oracles online that you can find explains that the oracle needs to have the key, then it's difficult to acquire that knowledge. To make matters worse, when you ask a question about cryptography, you get insulted on Reddit and confused by muddled replies on Cryptography Stack Exchange. You can't win.

[HACKERALERT]

Sorry for what is happening, but these were my real feelings at the time. If you don't want to take me seriously, that's up to you.

You've insulted me multiple times and are now trying to downplay it as if nothing happened.

Have you ever even tried explaining things to me? You know my Reddit username. You can PM me. And if you provide logical reasons as you did above, I would believe you. Because you haven't been open and explain things from your perspective, I look at things from a normal person's perspective. If I see someone who posts about his project, and the post and all replies are by u/[deleted], what do you think I would think about you? If you saw that, what would you think?

Then you had no context for the xkcd situation but believed his side of the story.

Because what he perceives is exactly what I perceive about you. If you don't explain the situation clearly, how am I supposed to know that it was his problem? No one is born evil and no one wants to deliberately hurt you. Not him, not me. But when someone takes an initiative to make a point, there's a reason. So either way, there was some error on your end that made this happen. I'm not saying he's all correct either, because he isn't.

And GPG? It serves more than just a tool. It's one of the first of it's kind and marks one of the first successful FOSS encryption tools. There are secure ciphers and hashes that it supports, so why would you remove it? Moving it to "Worth mentioning" is fine with me, but plainly striping it out as if it never existed is a terrible thing to do. You're taking away the credit of a previously great (and still is now) tool that was developed voluntarily and funded by Germany. Why remove it?

In response to xkcd's new comment, I don't understand cryptography in its entirety and can't read cryptography papers well. Neither of those things are required to write cryptographic software.

How about to tell that to Schneier or say that in r/crypto? I don't completely understand cryptography either. But when I can, I take the chance to ask questions and learn. Your attitude of saying a basic amount of knowledge is adequate is not healthy. No one is going to trust what you make if you say yourself that knowing cryptography doesn't matter for encryption software. I'm with xkcd on this one. The action is worth more than the gift.

If the books you have access to don't discuss oracles and no explanation of oracles online that you can find explains that the oracle needs to have the key, then it's difficult to acquire that knowledge.

And that's why I ask questions. If you're in a war and there's no food, are you just gonna say "there's no food, I'm not going to look for it"?

To make matters worse, when you ask a question about cryptography, you get insulted on Reddit and confused by muddled replies on Cryptography Stack Exchange.

This is false. Completely false. Absolutely false. Horrendously false. If you're going to deal with cryptography, you should have the guts and bravery to ask questions. Here's my Crypto SE account: https://crypto.stackexchange.com/users/82794/hackeralert. I've asked more than 10 questions. How many people laughed at me for doing so? None. Because asking is learning, and learning is understanding. And when you understand something, you are less likely to make mistakes.

You can't win.

I have. I've gained more knowledge from asking questions than reading documents.

If you don't believe me, that's fine. Just know that if you're willing, I'm happy to be friends or at least, not enemies any more. Your attitude needs to change. As Schneier said, security is a process, not a product. Your knowledge right now may serve you well, but if you're not willing to learn, you've just contradicted Schneier.

Take a moment to think about what I've said.

[lynn-stephenson]

but Samuel has been slowing me down, and it's not just me that disagrees with him (there are people on Reddit as well). The fact that he deletes his Crypto.StackExchange account immediately after asking a question says something about his character. I'll say no more, as I want to remain polite and civil.

@HACKERALERT

When I first read your post I managed to fly over this part. This GitHub issue is not a place for discussing someone's character, there has been valid criticism; but this has devolved into both aggressive, and passive aggressive insults. We're here to talk about your program.

However, while ChaCha20 is the default encryption algorithm in Picocrypt, I'm adding the option to cascade Serpent with ChaCha20 for better security, for the truly paranoid.

If you need resources, I can help with that.

I don't want to spam this issue with drama,

@samuel-lucas6 Except you continue to do so.

Thank you for your explanation, I respect your decisions and I've edited my remark off from my previous post. I just have one question: Why don't you want to be linked back to the questions you asked?

Take this elsewhere.

Thank you. But for the random nonces, here's what Monocypher's author says (https://monocypher.org/manual/aead):

Cryptography is hard. Random nonces are safely applicable in most areas, however absolutely not always. I do not know the specifics of file storage implications. So right now, I have nothing more to say on whether you should use a counter based nonce or not.

You can't win.

Let's not resort to this.

Whoo, drama out of the way. Time to drop it. Constructive criticism only. @samuel-lucas6 @HACKERALERT

[HACKERALERT]

Thank you for being neutral and pointing things out 🙏 . I will talk no more about this matter, I never wanted to and I don't enjoy doing so. And sorry to you @lynn-stephenson for being in a weird situation like this. I apologize if anything I have said offends you. I never want to hurt someone.

I have found a good-looking Serpent implementation by GitHub user aead (https://github.com/aead/serpent/). I haven't implemented it in Picocrypt yet, as I need to deal with partitioning oracle attacks first. Then I'll ensure that it matches the test vectors before cascading it with ChaCha20. I've pretty much searched the first 10 google pages for Serpent in Go and that's the only one I've found, unfortunately. Twofish would be another good choice, but golang.org/x/crypto/twofish (It's a supplementary package to Go's official crypto library) has marked Twofish as deprecated, so I'm a little hesitant about this one. Any ideas? Or perhaps I should just not use Serpent entirely, since as you have mentioned and I do agree with, Serpent doesn't have much of a practical edge over (X)ChaCha20. I would greatly appreciate your opinion here.

I think the best way to deal with these partitioning attacks is to drop the Poly1305 and just use plain XChaCha20 and BLAKE2 for fast mode, and SHA3 for regular mode. After some testing, the speed of XChaCha20 + BLAKE2 is a reasonable ~200 MiB/s, so that will be a great option for people who look for something fast. And XChaCha20 + SHA3 is great for people who need that extra peace of mind. Of course, BLAKE2 and SHA3 have similar security, so it's a matter of preference, and I intend on letting users choose.

I personally think XChaCha20 uses a 192-bit nonce so that we can choose at random. A 64-bit nonce is too little and a counter would indeed be preferable, but a larger space like 192-bit should allow choosing at random as well with no implications. Of course, this is debatable, and I think both are fine when the space is large enough. I'm open to your opinion if you manage to find anything about this.

Thank you for your help. It would also really help me if you answered this question: If there was one thing about Picocrypt that you disliked the most, which part/function/etc. would it be? I'm curious if there is something in particular that you don't like about Picocrypt, so that I can fix it if possible. I'm always open to constructive criticism.

Thank you again lynn for settling things down. I can't wait to see how Picocrypt will be going as I get in full swing again :)

Kudos to you 👍

[youdontneedtoknow22]

If there was one thing about Picocrypt that you disliked the most, which part/function/etc. would it be?

You'll probably find this silly but I'll say it anyways. Having the name "Hacker-Alert" and getting your program detected by AVs (Firefox didn't allow the download either, because it could potentially have malware) will put most people off. I used many programs in the past that were detected by AVs and I know AVs are shitty sometimes, but I doubt any other normal user would want to use your program. Telling users the program is open source won't solve the problem either, because most of them won't read the code. And power users would just go with Veracrypt.

The second thing is, you already pointed out in the download section that there's this outdated program also called picocrypt and you probably mean this (https://picocrypt.en.softonic.com/). I don't how things go on that website, but maybe you should try contacting them and telling them about your software and maybe they'll replace that outdated program. Many people will just google "Picocrypt" and download it from the websites they get from their search engine, and they probably won't go to the ones that start with (HACKERALERT), which is unfortunately your github repo.

edit: typo

[HACKERALERT]

Hi @youdontneedtoknow22, many thanks for lending me your opinion!

My GH username, HACKERALERT, is one I chose a long time ago when I never thought that I would be able to create something useful like Picocrypt, so there's not much I can do about it. Changing my username would leave HACKERALERT open and that could lead to impersonations, so I would prefer not to do that either. I generally don't think it'll be a big deal as long as I can solve the issue with AVs and browsers' inaccurate virus engines. Here's the deal... Picocrypt offers a file shredding feature, which on macOS and Linux, uses shell commands. On Windows, however, no command exists to shred a file, which is why I bundle sdelete64 from Microsoft sysinternals to do the heavy lifting. Of course, this means that I have to bundle sdelete64.exe along with Picocrypt somehow. I could pack things in a zip file, but that would be unwieldy and require manual user interaction, which is not ideal as Picocrypt is meant to be simple. So instead, I used the infamous IExpress to package Picocrypt. Unfortunately, hackers have exploited IExpress in the past, which is why it's common for a browser/AV to see an IExpress package to instinctively mark it as a virus, even though Picocrypt is not. Luckily, I came across Go's embed feature, which allows me to do directly embed files into the compiled executable, meaning that I won't need IExpress anymore. This is great for me, Picocrypt's startup speed, and to prevent AVs. This embedding will be present in v1.14, which I will release tomorrow and the day after that. Hopefully, that will solve this issue. Do you mind testing whether v1.14 is flagged by your browser when I release it?

For the outdated program, thank you for pointing out for me to contact Softsonic & co. in hopes of removing outdated software. I will do that shortly, and I do believe that they will be able to at least remove the outdated software. You just gave me the idea that maybe I should create a homepage for Picocrypt, acting as the canonical site. I have my personal site at evansu.cc, so perhaps I could make Picocrypt picocrypt.evansu.cc or evansu.cc/picocrypt. This should make things a little better, although I'm not sure for certain yet. I'll need to look into that.

Thanks for your valid points and for giving me some insight and ideas. I really appreciate it!

[youdontneedtoknow22]

Do you mind testing whether v1.14 is flagged by your browser when I release it?

I'll do it gladly :)

evansu.cc/picocrypt

This sounds like a good idea!

btw this was already mentioned, but your website doesn't work on my hardened Firefox either. It doesn't work on Brave too when the shield for fingerprinting is set to "strict", so I set it to "default" and it worked. When disabling "privacy.resistfingerprinting" on firefox, it still didn't work. So you might want to check that too.

[HACKERALERT]

Thank you very much! Do you think picocrypt.evansu.cc sounds better or evansu.cc/picocrypt? I prefer the latter, I think you might too since it was the one you mentioned, but just making sure.

btw this was already mentioned, but your website doesn't work on my hardened Firefox either.

Hmm... That's kind of sad. I like things fancy, so my site uses WebGL for the background animation. It seems that FF and Brave block WebGL to prevent canvas fingerprinting, unfortunately. I'll take a look and try to add a fallback. Thanks for confirming that this is an issue.

[HACKERALERT]

@youdontneedtoknow22 I've added a blank fallback background for my website evansu.cc. I tested on Brave and it works fine for me. Can you confirm that my site works with FF or Brave now? You might need to clear your cache. Thanks! Edit: spelling

[youdontneedtoknow22]

Your website works now with both firefox and brave on my end :)

And evansu.cc/picocrypt looks better for me. Oh and you're welcome, I should be thanking you for your project instead :)

[HACKERALERT]

Great! I think evansu.cc/picocrypt looks better as well, so I'll get working on it once I release 1.14 :)

[HACKERALERT]

@youdontneedtoknow22 I've released v1.14. Do you mind testing if your antivirus flags it? Thanks!

[youdontneedtoknow22]

@youdontneedtoknow22 I've released v1.14. Do you mind testing if your antivirus flags it? Thanks!

nope it doesn't flag it, It's "clean" :) However, it does get detected by some Antiviruses on VirusTotal, so you might want to work on that one too if you have some extra spare time. https://www.virustotal.com/gui/file/2d68f1304af7fc391f8453601f5039e732423b716b17eb7c625ff766973d3eb0/detection Microsoft defender doesn't seem to flag it on my device (but I didn't open the file), so I don't know how reliable that scan was. And it does seem to come because of UAC Prompt for asking for admin priviliages as I read somewhere. But I have no idea why it's being flagged as "Coinminer" from another random Antivirus.

[HACKERALERT]

Thank you very much for letting me know!

I sent the file to Google for scanning and it came out clean. Looks like embedding the file directly inside the executable is the way to go. I took a look at the VT result you posted. It looks like two AVs that I've never even heard of have flagged Picocrypt. But this is way better than v1.13, in which IIRC had a lot more flags.

And it does seem to come because of UAC Prompt for asking for admin priviliages as I read somewhere.

Just making sure, Picocrypt can run on your device without admin privileges, right? It's designed not to require it, so I would love a confirmation.

But I have no idea why it's being flagged as "Coinminer" from another random Antivirus.

LOL, I don't see how Picocrypt is remotely relatable to a coinminer. I think that random AV had a little seizure :)

Many thanks for helping out, I'll get started on the website soon!