Replying to
@everton137@social.vivaldi.net ugh. That is very depressing 😵
Remote
Heiko
@hko@floss.social
mastodon 4.7.3Various #OpenPGP-related activities, mostly in #Rustlang.
- Very lean modern OpenPGP: https://minipgp6.org/ (@minipgp6@floss.social)
- Contributor to @rpgp@mastodon.social
- Blog/writeups: https://openpgp.foo
- OpenPGP card (hardware security device) projects: https://codeberg.org/heiko#openpgp-card
369 Followers
174 Following
50 Posts
Joined April 28, 2025
codeberg:
OpenPGP for application developers:
v4 OpenPGP certificate:
v6/PQC OpenPGP certificate:
Apparently the so-called "schism" in #OpenPGP is over.
Context: In 2022, an email to the IETF OpenPGP working group list, titled "a new draft overlapping the WG draft", noted that one implementation (GnuPG) seemed to reject the draft that is now RFC 9580:
https://mailarchive.ietf.org/arch/msg/openpgp/PWp3ZcZ_qnDNLhuT-zR7gA2ddeg/
Today, the author of #GnuPG signaled on the IETF list that he intends to implement support for RFC 9580 and draft-ietf-openpgp-nist-bp-comp:
https://mailarchive.ietf.org/arch/msg/openpgp/B7ytSFXTVW84UfFd4cCW-DXhpAA/
As I see it, this is great news for OpenPGP!
@jonah@mastodon.neat.computer this is definitely a hard time to feel hopeful about tech.
My silver linings perspective is that we're collectively getting a lot of new clarity about what we disagree with, and what world we'd prefer to inhabit instead.
Some of the "evils" are new, but many have been here a long time, and we've just gotten better at seeing them with a critical eye.
Maybe this depressing moment is a necessary intermediate step towards making a better tech world for ourselves - and everyone.
Replying to
GnuPG exists for one sole reason:
The original PGP crew in the 1990s decided that open standards, collaboration and multiple implementations are cool.
So they published their - at the time groundbreaking - formats, and standardized them at the IETF.
GnuPG has benefited massively from this, while at the same time being a software that no one I know has ever truly enjoyed. I certainly have not.
This project is now attempting to do a standardization rug pull. It's ridiculous and enraging.
Replying to
@tante@tldr.nettime.org according to https://en.wikipedia.org/wiki/Electric_energy_consumption#World_electricity_consumption the global total electricity consumption is ~25.000 TWh.
That would make the aggregate current usage of the big tech corporations (as shown in Ketan's second image) very roughly 1% of all of humanity's electricity use.
Exponential growth continuing from currently ~1% sounds even more horrifying than what I had imagined so far. Here's hoping that this unhinged waste of energy stops sooner rather than later.
Replying to
As a total aside, this test-Gnuk is running on an ST-LINK v2 clone that I bought ~5 years ago when I first hacked on https://crates.io/crates/openpgp-card
See https://nx3d.org/gnuk-st-link-v2/ for more.
Replying to
@jas@fosstodon.org openpgp-nist-bp-comp (and the codepoints it will define) is only specified for use with version 6 keys:
https://www.ietf.org/archive/id/draft-ietf-openpgp-nist-bp-comp-04.html#name-key-version-binding
Additionally/separately, government agencies (including BSI) have been clear that they strictly require support for RFC 9580/9980/openpgp-nist-bp-comp from their vendors, going forward.
Yay for @dvzrv@chaos.social 's tireless(*) work towards modernizing how OpenPGP is used in distro contexts (including in Arch Linux).
I've spent some time last year hacking on https://devblog.archlinux.page/2026/verify-arch-linux-artifacts-using-voa-openpgp/ with David, which was a great time.
VOA is the other side of the coin to Signstar - the former verifies signatures, while the latter produces them.
---
(*) Although I do suspect he might at times actually get tired, after all 🤔
Replying to
@tarakiyee I love how the text doesn't aim to tear down an imperfect argument, but add to and improve it!
A discursive world with more principledness, but less tearing down would be nice 😃
I just released version 0.1.7 of rsop-oct, a stateless #OpenPGP ("SOP") CLI tool for use with OpenPGP card hardware devices:
https://crates.io/crates/rsop-oct/
Like its sibling project #rsop, rsop-oct is based on @rpgp@mastodon.social
This update adds (initial) support for the SOP command 'update-key'.
This command allows extending the expiration times of components of an OpenPGP certificate using a primary key that is stored on an OpenPGP card device.
For more on #SOP, see https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/
Replying to
A new and PQC-relevant email thread: https://lists.gnupg.org/pipermail/gnupg-users/2026-April/068280.html
I consider the author of that mail (@andrewg@mastodon.ie) one of the most evenhanded and patient people in PGP. He has a lot of context, both on the technical side, and regarding the social dimension.
His mail hits many nails on their heads. It's unfortunate that the PQC situation in OpenPGP (or well, in GnuPG) has derailed as it has. But here we are.
I'm glad Andrew is spelling out uncomfortable points. And still hopes for common ground.
The openpgp-card-state crate now has a new "ephemeral" backend:
https://codeberg.org/openpgp-card/state/#ephemeral-interactive-input-with-persistence-and-expiry
This combines the defensiveness of unpersisted pinentry with the convenience of caching (in the Linux kernel credential store, for a configurable duration).
New releases of https://crates.io/crates/openpgp-card-tool-git, https://crates.io/crates/openpgp-card-ssh-agent, https://crates.io/crates/rsop-oct support this new #OpenPGP card PIN storage backend.
Many thanks to @classabbyamp@chaos.social who implemented this new PIN handling mechanism in openpgp-card-state.
Replying to
@upofadown Schemes based on RFC 9580 are going to be quite interoperable.
I'm aware of at least 7 serious independent codebases that implement RFC 9580, and almost as many mature implementations of draft-ietf-openpgp-pqc.
Adding autocrypt2 to the mix is a very small additional layer on top of these already widely available building blocks.
(And sure, GnuPG is doing its own thing. But that is really not very relevant to Delta Chat or its users.)
Replying to
@liw I do think there are some reasons to worry - but not about skilled programmers losing their privileged position in the job market.
My impression is that a lot of the frenzied discourse is caused by two facts: 1) a few corporations are spending ridiculous amounts of money, and some of it on propagandizing, and 2) these LLM techniques do have some kernel of utility for some software engineering-related tasks.
I enjoyed the perspectives in this recent conversation: https://dair-community.social/@timnitGebru/116237328338979566
Replying to
I set up a containerized build environment to facilitate working on the GnuPG IETF PQC branch:
https://codeberg.org/freepg/freepg-draft-ietf-openpgp-pqc/src/branch/main/build
The goal of adding #IETF #PQC support to @freepg is still very many steps away. But it's nice to have a foundation to start from :)
Replying to
@neverpanic@chaos.social @darkuncle@infosec.exchange frankly, after observing this mess for quite a while, I think these explanatory models are not fully convincing. Sure, there are animosities, and they do play a role. But I don't believe they are the ultimate root cause.
About the technical "arguments" (such as the complaints about GCM in RFC 9580), I have come to believe that those are entirely disingenuous parallel constructions.
I just released version 0.1.9 of rsop-oct, a stateless #OpenPGP ("SOP") CLI tool for use with OpenPGP card hardware devices:
https://crates.io/crates/rsop-oct/
Like its sibling project #rsop, rsop-oct is based on @rpgp@mastodon.social
This version improves error handling and reporting in some cases, in particular when a suitable card is not found, or the User PIN for a card is not available.
For more on #SOP, see https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/
Replying to
@ell1e@hachyderm.io I was thinking the same thing as I wrote it - but then, they have decades of experience at being a wide range of shades of evil.
They probably don't need my advice.
Replying to
@ell1e@hachyderm.io "Digital Crimes" 🤦
Maybe they could also mix accusations of (cyber) "terrorism" into this matter 🤪
Replying to
My current goal for #minipgp6 is to clarify the target shape for an eventual v0.1.0 release.
The v0.0.x series serves strictly as a prototype. This is why v0.0.1 lives in the separate "draft" git branch.
Once prototyping is complete, I will start implementing the v0.1 series from scratch, in the git "main" branch.
Replying to
@hipsterelectron once the dust around the base minipgp6 stack settles, I plan to write a convenience crate for AC2 key generation and rotation.
Would love to hear your thoughts when you read the draft!
Replying to
@hipsterelectron thank you!
this needs so much work still, but it's such a relief to have put this initial version out in the world!
... a very smol pgp! 🥺🔏
Replying to
@hipsterelectron I have not engaged with that draft yet, but minipgp6 is conspicuously matching the algorithm requirements of the scheme 😏
Replying to
@duxsco@fedifreu.de The good thing is that no one is forced to deal with GnuPG's increasingly odd choices.
My perspective is that there is really only one sensible path forward: The formats that are developed by the OpenPGP WG at the IETF.
There are half a dozen independent implementations of both RFC 9580 and draft-ietf-openpgp-pqc.
It's clear that there is a lot of consensus, and will to modernize in a collaborative fashion.
Replying to
Replying to
@CyReVolt the naming of the https://freepg.org/ patchset might have included a smirk and a wink in that general direction
Replying to
@CyReVolt oh wow! I had no idea you were involved in that.
It's wild to think how many attempts to leave the gravity well of GnuPG there already were. Hopefully we'll reach escape velocity, finally.
Replying to
@giacomo I mean that GnuPG's new, non-OpenPGP formats are "proprietary in the governance sense":
One actor unilaterally decides what they want to do, while not meaningfully engaging with anyone else.
Then they implement their preference, and write up some document that more or less describes the format.
Think https://en.wikipedia.org/wiki/Office_Open_XML
Replying to
@darkuncle@infosec.exchange I find it truly hard to understand what exactly is going on with GnuPG, but I consider the analysis in
https://mastodon.ie/@andrewg/116464399797066586
one of the more compelling theories about why this is all unfolding as it is.
Replying to
Replying to
Replying to
@evan@cosocial.ca I'm glad these valiant truth-seekers have gotten the guy who spray paints hopeful symbolism on walls sorted.
I assume they will now shift their keen investigative minds to reporting about Palantir's sales process. Or whatever. This is going to be great!
Replying to
@andrewg@mastodon.ie @aspensmonster@tenforward.social @petelawler@mastodon.social I very much agree with Andrew's analysis.
(Fwiw, I think there is no conceivable monetary incentive for GnuPG to fork away from the OpenPGP standard.)
Replying to
@duxsco@fedifreu.de This is of course complicated by GnuPG effectively attempting to derail these developments
But I don't think there is anything constructive left to do, in that regard. Many people have tried to build many bridges. To no avail.
The only remaining option is to try and protect captive GnuPG user bases from the fallout, as much as possible. This is the goal of @freepg@infosec.exchange
The GnuPG situation is not great. But I think the ecosystem is being as constructive as circumstances allow. Which is nice
Replying to
The key material from RFC 9580 Appendix A.4 on my test Gnuk (https://www.fsij.org/doc-gnuk/intro.html)
$ oct status
OpenPGP card FFFE:57092840
Signature key:
Fingerprint: 060606060606060600000000cb186c4f0609a697
Creation Time: 2022-11-30 16:08:03 UTC
Algorithm: EdDSA (Ed25519)
Signatures made: 3
Decryption key:
Fingerprint: 06060606060606060000000012c83f1e706f6308
Creation Time: 2022-11-30 16:08:03 UTC
Algorithm: ECDH (Curve25519)
[..]
Replying to
@duxsco@fedifreu.de @giacomo 👍
It is confusing that two related but separate issues are overlapping here:
1) There is a Free Software codebase (GnuPG), the code of which is not "proprietary software" in the FSF sense.
2) However, this Free Software project is increasingly an implementation of a format ("LibrePGP") that is developed in a proprietary manner, in an entirely intransparent process.
Replying to
@jas@fosstodon.org I for one, have personally implemented support for decryption of the librepgp "type 20" AEAD encryption container in rPGP, sometime last year.
Interop is of course important (and I'm personally particularly interested in avoiding lock-in in semi-proprietary formats)