# Remove Picocrypt

**URL:** https://discuss.privacyguides.net/t/remove-picocrypt/29786
**Category:** Tool Suggestions
**Tags:** completed
**Created:** 2025-08-05T16:17:44Z
**Posts:** 46

## Post 1 by @fria — 2025-08-05T16:17:44Z

### Why should this tool be removed?

The developer of Picocrypt is archiving the project:

> [@I'm archiving Picocrypt](https://discuss.privacyguides.net/t/im-archiving-picocrypt/29785):
>
> It’s not ideal but that’s life. I’m moving into a different direction and am cleaning up some loose ends. I want to make sure I do the best I can for the project and its users before leaving. Read the issue fully… it’ll explain in detail. I think it’s also an interesting and somewhat ironic format. Looks like this means Picocrypt will no longer qualify to be listed on PG since Picocrypt for macOS will probably break soon and it won’t be cross platform anymore. The PG community can decide how …

Since it won’t be getting any more security updates, Picocrypt should be removed from the site.

PR: [update!: Remove Picocrypt by friadev · Pull Request #3086 · privacyguides/privacyguides.org · GitHub](https://github.com/privacyguides/privacyguides.org/pull/3086)

---

## Post 2 by @KevPham — 2025-08-05T16:39:01Z

Key kicker here is MacOS support.

While it won’t magically become useless in the future for Linux and Windows users , the lost of cross-platform support is a clear violation of the criteria we established.

---

## Post 3 by @anonymous378 — 2025-08-05T16:48:37Z

Even if MacOS support wasn’t an issue, wouldn’t it be kind of odd to have an archived project remain recommended?

---

## Post 4 by @KevPham — 2025-08-05T16:55:41Z

> [@I'm archiving Picocrypt](https://discuss.privacyguides.net/t/im-archiving-picocrypt/29785/1):
>
> I just want to make it clear that the software is still fully functional and no different, it’s just frozen. Unless the core cryptographic design is problematic, which is unlikely, you can continue using it for as long as you can get it running or running from source.

You may want to read his [statement](https://discuss.privacyguides.net/t/im-archiving-picocrypt/29785) on the forum and draw your own opinions on whether that is true or not. I am generally against the inclusion of archived projects.

---

## Post 5 by @Valynor — 2025-08-05T17:04:24Z

> [@KevPham](#):
>
> Key kicker here is MacOS support.

Is there any actual proof that macOS is going to drop openGL soon™?

---

## Post 6 by @HACKERALERT — 2025-08-05T17:36:16Z

No, but it is marked as deprecated so it’s very likely it’ll be removed at some point. Especially with the last few Intel macs hitting end of software support, I’d expect Apple to clean up old stuff like OpenGL within the next 3 macOS releases. I would be happy to be proven otherwise, of course.

Some side info: even though OpenGL is deprecated, credit where it’s due, Apple did still pay some care to maintain compatibility… the OpenGL “driver” in the latest macOS releases are actually a translation layer to Metal, not directly running on hardware like in older macOS. Technically, Apple should have no problem keeping OpenGL support forever if it’s just depending on Metal, but that would be uncharacteristic of typical Apple. There is also MoltenGL which is a sort of OpenGL → Metal translator but first, it’s paid, and second, only supports up to GL ES 2.0, not the full GL 3.2 Picocrypt needs. There is a potential way to get around all of this but it’s hacky and error prone: replace the current GUI library fork with upstream [GitHub - AllenDang/giu: Cross platform rapid GUI framework for golang based on Dear ImGui.](https://github.com/AllenDang/giu) , patch giu to use ebitengine as the backend instead of GLFW+OpenGL, then tell ebitengine to use Metal natively on macOS. Then do a bunch of patches to get drag and drop, system file selection dialogs, etc. working again. In theory this works, but I haven’t tried because it sounds like a pain. But if anyone wants to get Picocrypt working on macOS when it breaks, this might be a path forward. Or at this point, just rewrite the GUI entirely in ebitengine which from what I can tell, is the best choice for native Metal on macOS support going forward.

---

## Post 7 by @any1 — 2025-08-06T12:45:15Z

I wouldn’t remove Picocrypt just yet, since the future of OpenGL on macOS is unknown and might only become a problem much later than expected.

I would add a disclaimer under macOS stating that OpenGL has been deprecated since 2018 and may be removed in any future macOS version. Alongside that, include a link to the CLI version as an alternative if and when support disappears.

Since the cryptography in Picocrypt is solid—and unless something dramatic changes, allowing the encryption to be broken within a non-trivial timeframe—its current lack of updates shouldn’t significantly impact its security.

---

## Post 8 by @anonymous378 — 2025-08-06T12:49:54Z

Its hard for me to see how keeping this on after its archived isn’t against the [Active Development criteria.](https://www.privacyguides.org/en/about/criteria/)

> **Active Development** : The tools that we recommend should be actively developed. Unmaintained projects will be removed in most cases.

---

## Post 9 by @fria — 2025-08-06T13:11:46Z

There’s so many options for encryption on macOS that I don’t really see why it’s needed anyway, you can just use the built-in encryption tools or any number of other ones listed on the site.

---

## Post 10 by @Niek-de-Wilde — 2025-08-06T13:26:28Z

I second it that we cannot recommend software that is no longer being maintained.

---

## Post 11 by @fria — 2025-08-06T13:29:59Z

Between this and the other thread I think we have a majority approval so I’ll go ahead and mark it approved then.

---

## Post 12 by @hakavlad — 2025-08-06T15:09:38Z

I’d like to change the requirement from **‘actively developed’** to **‘basically maintained’**. Tools that are stable and already secure do not require ACTIVE development.

---

## Post 13 by @any1 — 2025-08-06T17:08:38Z

I am currently writing a new GUI for PicoCrypt that should work on almost all desktop hardware made after 2012 (excluding MacBooks made before 2015, and possibly Android, iOS, and web). Since this is my first time working with Go, I’m not entirely sure about support on Android, iOS, and web. I will try to get a working build out as soon as possible, but depending on my schedule and the fact that I’m still learning Go, it might take a bit longer.

 ![picocrypt](https://forum-uploads.privacyguidesusercontent.com/original/2X/4/482435ffa228a4f06069080427cbcb3efdbb062f.png)

---

## Post 14 by @HACKERALERT — 2025-08-07T02:55:31Z

@any1, can you link me to the GUI library being used? I’m a bit concerned it still depends on OpenGL by the looks of it.

---

## Post 15 by @anonymous390 — 2025-08-07T03:27:41Z

Nice! FYI, a former major Picocrypt contributor is also working on a fork, called [Picocrypt-NG](https://github.com/Retengart/Picocrypt-NG).

@overdrawn98901 you may be interested in the post I’m replying to, as well as my reply

---

## Post 16 by @HACKERALERT — 2025-08-07T17:00:43Z

Yes, I’ve created [Picocrypt-NG · GitHub](https://github.com/Picocrypt-NG) where I’ve invited trusted contributors to continue the project.

---

## Post 17 by @any1 — 2025-08-07T19:00:24Z

Don’t worry—it can compile as OpenGL 4.3 or OpenGL ES 3.0 for Linux, OpenGL 4.3 or D3D11 for Windows, and OpenGL 4.1 or Metal 2 for macOS.

> [@HACKERALERT](#):
>
> Yes, I’ve created [Picocrypt-NG · GitHub](https://github.com/Picocrypt-NG) where I’ve invited trusted contributors to continue the project.

I worked a bit more on it today, finished the GUI, and started removing the existing GUI calls. If you’ve already found more trusted or capable people to take over PicoCrypt and don’t need my work, let me know.:slightly_smiling_face:

Here’s a pic of the finished GUI (ignore the weird colors at the bottom—I was testing something)

Edit: by finished I mean a working gui not a pretty one

 ![picocrypt](https://forum-uploads.privacyguidesusercontent.com/original/2X/0/0dadb9319a277c2d2fdf8c95f62332600940f9d1.png)

---

## Post 18 by @HACKERALERT — 2025-08-07T19:17:24Z

I could definitely still use your help! The GUI is still a problem and the new org doesn’t solve that on its own.

What is this magical GUI library that I couldn’t find after years of searching lol?

---

## Post 19 by @HACKERALERT — 2025-08-07T19:18:17Z

Also, your GitHub username?

---

## Post 20 by @any1 — 2025-08-07T19:50:29Z

It’s a great single-header C library called [sokol\_gfx.h](https://github.com/floooh/sokol?tab=readme-ov-file#sokol_gfxh) (with nuklear.h for the GUI). I’ve been keeping an eye on it for the past few years, and I recently started using it for a personal 3d graphics project, so it wasn’t too hard to get something running quickly.

> [@HACKERALERT](#):
>
> Also, your GitHub username?

I’ll make a GitHub account tomorrow since my old one is deleted.

---

## Post 21 by @HACKERALERT — 2025-08-07T20:06:12Z

It’s in C, no wonder I wasn’t looking for it. If you’re happy to deal with cgo, that’s cool. Does it support drag and drop files?

---

## Post 22 by @anon11657877 — 2025-08-07T20:17:35Z

Depends on the tool.

Browsers, messengers, and pretty much anything else that connects to the internet requires active development.

Encryption tools like Picocrypt, most video games, offline media players, and text editors usually don’t. I think @HACKERALERT used to have that in his Picocrypt FAQ.

Should Picocrypt-NG be recommended or should we wait a while to see if this project will survive in the long run?

---

## Post 23 by @anonfox — 2025-08-07T20:27:49Z

> [@anon11657877](#):
>
> Encryption tools like Picocrypt

Why? They can have vulnerabilities that cause weaknesses in their encryption

> [@anon11657877](#):
>
> offline media players

Not if the media is untrusted. Media players exploits have been used in the wild before ( [Privacy-Focused OS Wants to Know How Facebook and the FBI Hacked it](https://www.vice.com/en/article/privacy-focused-os-tails-wants-to-know-how-facebook-and-the-fbi-hacked-it/) )

Might be the same for text editors and untrusted text files, but not sure

---

## Post 24 by @any1 — 2025-08-07T20:51:11Z

Yes, drag-and-drop works (see my last pic, top left). I’ll add smaller details like file size after drag-and-dropping, theming, and different colors depending on input/state once I get the main encryption and decryption working.

By the way, is maliciously crafted file or text input to exploit the GUI something that PicoCrypt should prevent, or is it out of scope?

---

## Post 25 by @overdrawn98901 — 2025-08-07T21:09:31Z

I’d also be interested in helping, but more so on the cryptographic core maintenance. Been studying cryptography and have wanted a good project to study and see how the implementation is, so this would be a good opportunity. But my spare time is quite little sadly.

---

## Post 26 by @HACKERALERT — 2025-08-07T21:15:51Z

That’s awesome! Great work.

It should be prevented if possible. Picocrypt assumes the user’s host machine is trusted but not any volumes dropped onto it. So you should not be able to drop a volume and execute arbitrary code, etc.

---

## Post 27 by @HACKERALERT — 2025-08-07T21:16:43Z

Feel free to study it, but there’s nothing to change or maintain… it’s secure as is and changing it would invalidate the audit.

---

## Post 28 by @overdrawn98901 — 2025-08-07T21:18:51Z

In that case, I’ll probably stay as an external contributor as I’m not as interested in GUI maintenance. But looks like there are a lot of people willing to help which is great!

---

## Post 29 by @HACKERALERT — 2025-08-08T02:00:45Z

I’ve been receiving some… unideal… comments in other places and emails and it’s really starting to take a toll on me. It seems like I’m the one that needs to touch some grass. So I’m signing off. I’ve set up a successor which I think is the big important takeaway in this thread. Thank you all of PG for being engaging, friendly, and supportive. PG is one of the best online communities I’ve had the pleasure of seeing. Farewell!

---

## Post 30 by @HACKERALERT — 2025-08-08T02:02:24Z

Edit: was trying to reply to any1 but both any1 and overdrawn have similar icons and as mentioned, I need to touch grass :joy: so misclicked. Disregard this message.

---

## Post 31 by @HACKERALERT — 2025-08-08T03:46:34Z

Can you give me your GitHub username when you make one? I’ll bring you in as a member if that’s good with you.

---

## Post 32 by @hakavlad — 2025-08-08T10:02:09Z

NG is not yet stable.

---

## Post 33 by @any1 — 2025-08-08T16:05:11Z

[Just made a new one](https://github.com/any1here)

---

## Post 34 by @any1 — 2025-08-08T20:09:45Z

Discussion has moved to the [Picocrypt-NG issues](https://github.com/Picocrypt-NG/Picocrypt-NG/issues) in case anyone wants to stay informed.

---

## Post 35 by @Viper — 2025-08-10T10:02:12Z

called it :face_with_tongue:

> [@Picocrypt dev taking a break, don't know if they're coming back or not](https://discuss.privacyguides.net/t/picocrypt-dev-taking-a-break-dont-know-if-theyre-coming-back-or-not/21655):
>
> As per title Well it’s still good for now but tomorrow person_shrugging

---

## Post 36 by @pika — 2025-09-12T09:00:09Z

Disappointed picocrypt was removed so soon !

Despite the developer urging that the software doesn’t become insecure or broken automatic, if he leaves active development.

Picocrypt is a very useful software for securely encrypting files. It was particularly helpful for me to create encrypted backups of my drives , as it was highly performant and secure too, compared to what other solutions had to offer like veracrypt or cryptomator.

I don’t really feel there is a replacement for picocrypt currently, so it should be still be kept on privacyguides recommendation.

---

## Post 37 by @Niek-de-Wilde — 2025-09-12T09:05:11Z

Well we are not saying people should hurry and deinstall it. But we are removing it since we should not be recommending people to go a download software thats not maintained or updated.

If a security issue happens tommorow, it might take ages for people who downloaded it to take notice.

---

## Post 39 by @pika — 2025-09-12T09:26:13Z

Well for that matter even [openkeychain](https://github.com/open-keychain/open-keychain) should be removed as its practically not being maintained and is just given version bumps every 8-10 months with some cosmetic changes.

The original developer had even announed that he is no longer continuing to maintain it. With uncertainty from new guy whether they will even look after any new maintaince or fixing required.

Atleast the picocrypt dev was very upfront about his stance and made it a public archive

I understand that you don’t want new people downloading software which doesn’t have a guranteed future, but still as the dev has shown confidence in the software being safe in the relative future , so it could be kept little longer. Maybe give a **Deadline for 5-6 months for delisting** if no suitable devs are willing to continue to maintain it.

---

## Post 40 by @Niek-de-Wilde — 2025-09-12T09:29:04Z

We could certainly discuss altering the requirement, but that we be another discussion. Right now as it stands we require software to be maintained to be listed. If anyone finds that a piece of software is not maintained, they can help us by opening another forum post where they point it out, so we can take a look at it.

---

## Post 41 by @pika — 2025-09-12T09:57:37Z

If you look at the argument for keeping openkeychain alive by a team member it was “lack of current alternatives” despite not currently being maintained.

> [@Reconsider OpenKeychain](https://discuss.privacyguides.net/t/reconsider-openkeychain/16329/9):
>
> We’re aware of this, but given the nature of it, (there are no alternatives) we haven’t de-listed it.

I am making this same argument for picocrypts case.

Although “officially” openkeychain say they are gonna do security fixes but there hasn’t been actual actions which shows fixing security issues and are probably using EOL version of openpgp protocol.

I am surely gonna make a new proposal for delisting openkeychain. But just to make sure both projects get equal treatment here.

Does the dev of picocrypt considers picocrypt a vulnerable software ? - No

---

## Post 42 by @ph00lt0 — 2025-09-12T10:06:41Z

Please go to the discussion about that as @Niek-de-Wilde suggested. It is very off topic here.

---

## Post 43 by @pika — 2025-09-12T10:21:32Z

> [@ph00lt0](#):
>
> suggested. It is very off topic here.

I am not sure how its off-topic when i am making argument for keeping picocrypt still listed on PG ,as still in par with the standards applied to other products in the same category.

Maybe you should go over my post again to understand its relavance.

Thanks

---

## Post 44 by @Niek-de-Wilde — 2025-09-12T10:40:26Z

Look, there are 3 seperate topics here.

1. Picocrypt is no longer being maintained, our requirements require that they have to be maintained \> Picocrypt is being removed.
2. You may argue that we should build in a buffer for the above mentioned requirement, thats fine and we can discuss that, but that will have to get its own seperate post where we can discuss it and decide, for as long the requirement has not altered, Picocrypt still had to be removed.
3. You argue that openpgpchain is not maintained, maybe it have to be removed, then the proper course is to open up a post for its removal just like a post was opened for Picocrypt.

We have to maintain the forums structure and rules, else its gonna be hell for people to figure out why something has been removed/added/altered because they have to search information in posts that aren’t even about the product or service they are looking for.

I am not saying your point is invalid. I am just pointing out that this is not the place to discuss it, not with these arguments, atleast.

---

## Post 45 by @anon39279085 — 2025-09-12T12:49:10Z

> [@pika](#):
>
> I am not sure how its off-topic when i am making argument for keeping picocrypt still listed on PG ,as still in par with the standards applied to other products in the same category.

PG will Remove Picocrypt in favour of Picocrypt-NG, no argument, no cap, no nothing.

Picocrypt-NG is literally the same Picocrypt (fork), no reason not to remove Picocrypt when the NG fork exists.

---

## Post 46 by @redoomed1 — 2025-09-12T13:53:50Z

#completed and included in the most recent release:

> [@2025.09.12](https://discuss.privacyguides.net/t/2025-09-12/31022/1):
>
> update!: Remove Picocrypt by [@friadev](https://github.com/friadev) in [#3086](https://github.com/privacyguides/privacyguides.org/pull/3086)

---

## Post 47 by @redoomed1 — 2025-09-12T13:53:55Z


