Thanks to the legendary Mikołaj, who rolled in this morning and pushed us past the $3.5k goal, we can finally get a security audit!
I have contacted Radically Open Security for next steps. This issue exists for people who want to get the latest updates on the security audit. Just look to the right and click “Subscribe” under the Notifications section and you’ll be notified whenver I have a new progress update.
That’s all for now. Thank you for reading and of course Mikołaj for pushing us past the finish line. I’m extremely excited that after 3 years of refinements to a stable, simple tool, we are now ready to make it certified secure.
Hi @HACKERALERT cool audit, any updates on mitigating the findings?
PCC-003 seems indeed more troublesome but I am actually wondering about the PCC-006 too. Using two hash functions leading to the same key seems undesirable, was that done my accident or by design? Hope you dont mind me asking I am just curious.
No problem asking of course, when I was designing it I had simplicity as one of the core ideas, so I decided to store a hash of the derived encryption key so the app can differentiate between things like corrupt header, volume data is modified, and incorrect password instead of just a generic error because there’s not enough data to determine the error cause. In the GitHub thread in the OP I have some additional updates, tl;dr I fixed most things already apart from two issues that I explain in the thread. PCC-006 is one of them, justification being the SHA3-512 hash is of the Argon2-derived password (not the password itself) and so it already has “256 bits of entropy” (the salt helps with this) and thus is impractical to bruteforce. SHA3-512 has not been broken in any significant way afaik and likely will remain like that for a long while. So, storing a hash of the derived key shouldn’t decrease security as long as Argon2 and SHA3 do their job. Interested in hearing if this answers your concern or you have other reasons to talk about
Thanks for the answer, where is that github thread? I am also believing this is purely theoretical but you are increasing the attack factor by allowing two paths to the key. It’s something i was always taught to avoid. While i believe both hash functions to be strong we never know what the future will bring.
The thing is that on desktop we have many options and we are pretty much covered on encryption tools, small or big.
Mobile is another thing though, where we basically have zero free and open source good cross-platform file encrypting tool options.
Even Cryptomator’s android freemium model is already at 2 years “in the works”…
If only, somehow, Picocrypt can expand to Android and iOS would be more than amazing.
Yes, that’s a totally reasonable justification. I suppose we can think about how to remove the SHA3 hash if people are okay with more generic error messages. I’ve opened this for further discussions and ideas:
@mentalfoss The GUI library used doesn’t support Android/iOS so it would take a lot of effort to move the existing desktop app to another library. Currently there is a web app https://picocrypt.pages.dev which works on mobile, albeit very limited. There’s a Mobile repository under the organization where future native mobile apps can be built, but I don’t have any time or plans for it at the moment.
Don’t plan to work on it myself as it’s not my area of expertise. I’ve tried it in the past and (at least back then) Flatpak for Go apps is just a glorified script to compile it from source, not that different from just using the raw executable. There’s an issue open for it though, so if someone more familiar with the packaging wants to help, there’s potential there.
I also think I others have packed it for AUR and Nix so that’s nice. Cool little site I found:
Per your request on GH 