New on my blog: Why I use OpenPGP and how you can too

In an era where our most personal conversations travel through countless servers, encryption has never been more crucial. In my latest article, I explain why OpenPGP is my go-to tool for secure communication.

What you'll find:

- Clear explanation of OpenPGP fundamentals
- Interactive demo to try it yourself
- Practical setup guides for all platforms
- Real-world insights from IT practice

OpenPGP is more than just encryption - it gives you back control over your digital privacy. No dependency on companies that might change their policies.

Read more: https://blog.klein.ruhr/why-i-use-openpgp-and-how-you-can-too/

Any software that needs to encrypt data using OpenPGP, or to verify an OpenPGP signature on data, should use the stateless OpenPGP interface, or SOP, which is provided for a number of OpenPGP implementations. Using any other interface is going to lock in the software to that implementation.

Also, SOP is lovely to use from another program. It's designed to be nice to use from a program.

https://openpgp.foo/learn/sop/

News from the coalface:

Upgrading the #Hockeypuck #openpgp #keyserver in-place has historically not been a smooth experience. In particular, the search indexes are only updated on write during normal operation, and the database schema is not updated at all. When major changes are made to the back end code, the dataset therefore has to be dumped and reloaded. This requires double the disk space and adds to the burden of maintaining a keyserver.

In preparation for #rfc9580 and #pqc keys, we have been working on in-place migrations for the search indexes and database schemas. The hockeypuck master branch now reindexes search terms transparently on startup, which will ensure consistent search results after any changes to the indexing policy. We are also testing a feature to reload the full dataset in-place after an upgrade, which must be run in offline mode due to concurrency limitations, but should otherwise be seamless and does not affect resource usage. Together these changes will reduce the maintenance burden for keyserver operators, and smooth the path for future upgrades.

In-place post-upgrade migrations, plus improved sync resilience, and hopefully a few additional improvements (watch this space!), will be available in the forthcoming 2.3 release, which is generously supported by @NGIZero Core.

#PGP bzw. genauer #OpenPGP gibt es in verschiedenen Standards:
- RFC 2440
- RFC 4880
- RFC 9580 und
- LibrePGP

Johannes Roth und Falko Strenzke haben die Unterschiede zwischen den wichtigsten Standards herausgearbeitet:
https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison

New blog article: "Using a second #OpenPGP card for my primary key"

https://openpgp.foo/posts/2025-07-a-second-card/

This is a rather niche article, but I hope it will still contain some bits of interest, for at least some readers .

In it, I import my primary OpenPGP key onto a second OpenPGP card hardware device, and use the device to issue a third-party certification with rsop-oct.

I also outline some background and tradeoffs around different OpenPGP card setup.

I just released version 0.1.3 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

This update adds support for the SOP command 'certify-userid'.

This allows issuing certifications (aka "third-party signatures") over identities in other people's OpenPGP certificates, directly with an OpenPGP card device.

For more on #SOP, see https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

Stimmt doch bitte alle mal diesen Feature Request für #GLPI ab. #OpenPGP-Support innerhalb des Ticketsystems wäre eine wahnsinnig hilfreiche Sache.

https://glpi.userecho.com/communities/1/topics/886-please-add-pgp-support

A new report (commissioned by the German BSI) outlines the recent evolution of the #OpenPGP standard, including the new RFC 9580 and PQC drafts, as well as the spinoff "LibrePGP" draft that the GnuPG project writes.

PDF: https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison/releases/download/v1.4/opgp-lpgp-comp.pdf

(Announcement email: https://mailarchive.ietf.org/arch/msg/openpgp/2g_rjYBqwqKZE6OEgjNb0bFo098/)

Note that the document contains a one-page "Executive Summary", which (although quite technical) is worth a read.

[TL;DR: It raises concerns about the GnuPG draft's development process, as well as quality]

Created a FreeBSD port for openpgp-card-tools and put it on my Codeberg:

https://codeberg.org/Larvitz/openpgp-card-tools-freebsd-port

It's a command-line-utility (oct), written in Rust, to manage openpgp smartcards and compatible devices (yubikey, nitrokey etc).

Usage instructions are in the repositories readme file.

#freebsd #openpgp #rust #port @hko

The amazing openpgp-card-tools(1) and openpgp-card-ssh-agent(2) compile and work perfectly fine on FreeBSD 14.3-RELEASE.

Can properly use my OpenPGP card to authenticate against SSH servers and use oct to manage my cards.

The only preperations, I had to make in order for it to work:

pkg install pcsc-lite pcsc-tools ccid
sysrc pcscd_enable="YES"

Amazing! I love those utilities from @hko

1: https://crates.io/crates/openpgp-card-tools
2: https://crates.io/crates/openpgp-card-ssh-agent

The PGP Problem

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/

Seit einiger Zeit signiere ich meine Mails mit OpenPGP.

Oft kommt die Rückmeldung: "Ich kann die Anhänge nicht öffnen."

Das ist sehr schade. Ich hätte gehofft, dass auch nicht IT-Nerds es schaffen, den Anhang mit Endung .asc zu ignorieren oder eine Suchmaschine dafür anwerfen.

Das Problem würde sich übrigens lösen, wenn öffentliche Stellen, Ärzte, Versicherung etc. auch verschlüsselte Mails nutzen würden.

I just learned that when encrypting email with PGP, the subject line of the email is NOT encrypted. Two things about this fascinate me:

- what a glaring oversight. How did anyone ever think that not encrypting the subject line was a good idea

- why is this not more commonly known? i feel like every guide how to use PGP for email should be screaming from the rooftops: "TAKE NOTE THAT THE SUBJECT LINE OF YOUR EMAILS IS NOT ENCRYPTED". Instead, I just found it deep in the details of one such guide. Many guides (yes I checked several) don't include this information at all.