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.

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]

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

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.

Automated digital signing of OS artifacts

https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/BOMYF4UTJJ37UIBXW52OU7WJTT3YPTKS/

"CVE-2025-47934 – Spoofing OpenPGP.js signature verification"

https://codeanlabs.com/blog/research/cve-2025-47934-spoofing-openpgp-js-signatures/

Comparing #XMPP against #email protocols is too limited. What sets #deltachat apart is *vertical integration* and being driven by UI/UX considerations. Cross-platform Apps and Bots use the Rust core library which connects with #chatmail relays and classic email servers based on a higher level API -- abstracting over SMTP, MIME, #OpenPGP etc. See https://chatmail.at

#webxdc apps in turn use an even higher level stable API abstracting over email/xmpp/... see https://webxdc.org/docs/

The PGP Problem

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

#OpenPGP #GnuPG #PGP #GPG #PublicKey #Email

#AgeEncryption https://age-encryption.org
#Minisign https://jedisct1.github.io/minisign/

#AgePublicKey
age1s3n5ehvm8h3xjkc985hzjznw9cv0lk9ezj5heyy4m7l654rkzslq07ylps

#MinisignPublicKey
RWRK8XFYuCHjYX1J/7cKCUy6eQKNYVAurb/70Q6pK8kjGHALVORZGJ+o

I just released version 0.1.2 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 makes integration with https://crates.io/crates/openpgp-card-state optional.

rsop-oct can now implicitly use persisted PINs via openpgp-card-state, or explicitly provided ones via the standard SOP CLI parameter '--with-key-password'.

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

I just released version 0.7.0 of #rsop, a stateless #OpenPGP ("SOP") CLI tool based on @rpgp:

https://crates.io/crates/rsop/

This version uses the new rPGP 0.16.0, with streaming message support.
It also comes with a number of bugfixes.

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

New release: #rPGP version 0.16.0

https://github.com/rpgp/rpgp/releases/tag/v0.16.0

#OpenPGP implemented in pure #Rust, permissively licensed

This release features streaming message support: Now rPGP can process arbitrarily large messages, with modest memory requirements.

It adds experimental support for the upcoming OpenPGP #PQC IETF standard https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc

This release also brings various improvements for key generation, support for X448/Ed448, and many minor fixes.

our friends over at @rpgp just published a monster milestone, humbly tagged 0.16 with

- streaming decryption and encryption

- post-quantum-cryptography

- API streamlining.

#rPGP is a full Rust implementation of #openpgp which counts among the fastest and most compliant implementations today, and includes security audits. Note: #deltachat uses a restricted subset of OpenPGP, and follows best practices (eg using the same ed25519 keys implementation as #signal) https://github.com/rpgp/rpgp/

Don't use PGP with emails.

> Security researchers are sounding the alarm over a fresh flaw in the JavaScript implementation of OpenPGP (OpenPGP.js) that allows both signed and encrypted messages to be spoofed.

> Discovered by Codean Labs' Edoardo Geraci and Thomas Rinsma, the vulnerability essentially undermines the core purpose of using public key cryptography to secure communications.

**OpenPGP.js bug enables encrypted message spoofing**

https://www.theregister.com/2025/05/20/openpgp_js_flaw/

A critical flaw in #OpenPGP.js lets attackers spoof message signatures
https://securityaffairs.com/178131/uncategorized/a-openpgp-js-flaw-lets-attackers-spoof-message-signatures.html
#securityaffairs #hacking

I'm launching a new site about #OpenPGP:

https://openpgp.foo/

This site is a personal writing project with a focus on learning OpenPGP's concepts by playful hands-on use.

My goal is to empower readers to make sense of more advanced material (including https://openpgp.dev/), and become proficient in whatever subset of OpenPGP they are interested in.

The site is far from complete, I hope to continue writing on it. Let me know what you think, and what additional content you'd like to see!

@delta

Did you see this (german) presentation about openPGP and that it should not be used. What is your take on this?

https://youtu.be/1Og17xy4wlM?si=bgHUmBFaufQ5MXvq

When Code Became a Weapon

It's easy to take strong encryption for granted, but that hasn't always been the case. This week we're diving into the "Crypto Wars," covering historical attempts by the US government to restrict strong encryption being exported internationally.

https://www.privacyguides.org/videos/2025/05/08/when-code-became-a-weapon/

Let us know what you think of this style of video! We're trying something different, and this is the first in a planned series lined up