Mastodawn

We are pleased to announce the release of Hockeypuck 2.3.2.

Hockeypuck 2.3.2 is primarily a bugfix release to revert a cryptographic policy default in go 1.24 that rendered some historical keys unverifiable. It also fixes some papercuts in the build process and improves the efficiency of database cleanup.

* Permit small RSA keys (reverts go 1.24 policy to that of 1.23)
* Clean more than one database entry per hashquery
* Use apt-get instead of apt in build scripts
* Match go patch versions between Dockrfile and go.mod

There are no breaking changes between the 2.2 and 2.3 branches, and SKS sync is supported between 2.2 and 2.3 peers.

Release notes can be found at https://github.com/hockeypuck/hockeypuck/releases/tag/2.3.2

Hockeypuck 2.3 development is kindly supported by @NGIZero Core

----

Hockeypuck is a modern synchronising #OpenPGP #keyserver that is optimised for ease of deployment, particularly in containerised environments via docker-compose.

https://
hockeypuck.io/
https://
github.com/hockeypuck/hockeypuck

PGPkeys EU Jan 25

We are pleased to announce the release of Hockeypuck 2.3.1.

Hockeypuck 2.3.1 is primarily a bugfix and maintenance release:

* Fix broken delete-keys helper script
* Bumped dependencies and refactored redundant code paths
* Improved PKS support
* Config parameter to increase the number of results returned from a search

There are no breaking changes between the 2.2 and 2.3 branches, and SKS sync is supported between 2.2 and 2.3 peers.

Release notes can be found at https://
github.com/hockeypuck/hockeypuck/releases/tag/2.3.1

Hockeypuck 2.3 development is kindly supported by @NGIZero Core

----

Hockeypuck is a modern synchronising #OpenPGP #keyserver that is optimised for ease of deployment, particularly in containerised environments via docker-compose.

https://hockeypuck.io/
https://github.com/hockeypuck/hockeypuck

Hockeypuck

PGPkeys EU Dec 28

Show thread

Heiko Dec 27

@upofadown If you want to talk about "vindictive incompatibility", a better example of that is the absolutely bizarre decision of #GnuPG to break away from https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/

GnuPG forked that draft with barely a pretense of an actual reason, and is now seemingly trying to speedrun a rollout of that incompatible non-IETF #PQC format (including by apparently trying to nudge people to switch to the 2.5.x series by avoiding tagging new releases in the 2.4 series)

Post-Quantum Cryptography in OpenPGP

This document defines a post-quantum public key algorithm extension for the OpenPGP protocol, extending [RFC9580]. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public key encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme.

IETF Datatracker

PGPkeys EU Dec 26

DD9JN Dec 26

https://www.gnupg.org/blog/20251226-cleartext-signatures.html

Cleartext Signatures Considered Harmful

PGPkeys EU Dec 13

Delta Chat Dec 13

On this day, two years ago, we published the first chatmail relay, https://delta.chat/en/2023-12-13-chatmail along with templates to replicate the setup, without needing any permission. Two weeks ago we thought there are 60 relays when a hacker handed in a 100+ list 😂
A bunch of knowledgeable folks are now maintaining track of health of the evolving global network, and supporting new operators. 💜💥🖤

thx also for all the support here on the fediverse! its been a wild year and #39c3 is in 13 days to top it off 😅

Delta Chat: Chatmail - replicable, fast and secure chatting infrastructure for all

Today, we are unveiling chatmail services, making onboarding with Delta Chat a breeze, with peace of mind: Convenience: Get a chatmail address in a few seconds Privacy: No questions asked, no name,...

PGPkeys EU Dec 9

PGPkeys EU Dec 8

New Blog: #Keyserver Updates and Roadmap, December 2025

...

About half of the public #Hockeypuck keyservers have been upgraded to the 2.3 branch (as of 2025-12-08), including the pgpkeys.eu servers. A small number remain on 2.1 for compatibility reasons, but the remaining issues preventing upgrade of these 2.1 servers will be addressed in an upcoming 2.3.x release.

...

While HKPv2 and RFC9580 support are the current priorities, further improvements are planned for delivery in 2026 and 2027. These include:

* Allowing #OpenPGP key owners to explicitly restrict the distribution of third-party signatures over their User IDs, to prevent signature flooding.
* Out of band email proofs of User ID validity, to mitigate spam and impersonation.
* A fully-featured management API to better handle deletion and blocklisting of incorrect or spammy keys.
* Native rate limiting and tor exit node abuse detection.
* Detection (and potential removal) of keys with known vulnerabilities or weaknesses.
* Improvements to the dump and restore process to allow a running server to be backed up without a restart.

https://blog.pgpkeys.eu/keyserver-roadmap-2025-12.html

#infosec #cryptography #pgp

Keyserver Updates and Roadmap, December 2025

An occasional blog about OpenPGP keyservers and related issues

blog.pgpkeys.eu

PGPkeys EU Dec 8

New Blog: #Keyserver Updates and Roadmap, December 2025

...

About half of the public #Hockeypuck keyservers have been upgraded to the 2.3 branch (as of 2025-12-08), including the pgpkeys.eu servers. A small number remain on 2.1 for compatibility reasons, but the remaining issues preventing upgrade of these 2.1 servers will be addressed in an upcoming 2.3.x release.

...

While HKPv2 and RFC9580 support are the current priorities, further improvements are planned for delivery in 2026 and 2027. These include:

* Allowing #OpenPGP key owners to explicitly restrict the distribution of third-party signatures over their User IDs, to prevent signature flooding.
* Out of band email proofs of User ID validity, to mitigate spam and impersonation.
* A fully-featured management API to better handle deletion and blocklisting of incorrect or spammy keys.
* Native rate limiting and tor exit node abuse detection.
* Detection (and potential removal) of keys with known vulnerabilities or weaknesses.
* Improvements to the dump and restore process to allow a running server to be backed up without a restart.

https://blog.pgpkeys.eu/keyserver-roadmap-2025-12.html

#infosec #cryptography #pgp

Keyserver Updates and Roadmap, December 2025

An occasional blog about OpenPGP keyservers and related issues

blog.pgpkeys.eu

Show thread

PGPkeys EU Dec 3

@atoponce we’re hoping that https://datatracker.ietf.org/doc/html/draft-ietf-mailmaint-unobtrusive-signatures might make a dent in those numbers… 😬

Unobtrusive End-to-End Email Signatures

This document deals with end-to-end cryptographically signed email. It introduces a novel structure for signed email that is designed to avoid creating any disturbance in legacy email clients. This "unobtrusive" signature structure removes disincentives for signing email.

IETF Datatracker

Show thread

PGPkeys EU Dec 3

@oneloop The two main differences between hockeypuck and sks-keyserver are 1. hockeypuck checks signatures and enforces good behaviour, whereas sks-keyserver allowed all sorts of mangled and abusive nonsense to be uploaded and 2. hockeypuck is a proper multithreaded web server.

The second point might seem trivial but it makes a huge difference - sks-keyserver could only serve one request at a time, and “requests” included sync operations, so it would become unresponsive for minutes at a time, and needed quite a complex load balancing apparatus in front to make it any way reliable. Wheres hockeypuck just works… 😇

Show thread

PGPkeys EU Dec 3

@oneloop in what way is what different? Is this a reply to a different post perhaps…?

website	https://spider.pgpkeys.eu
github	https://github.com/pgpkeys-eu
matrix	https://matrix.to/#/%23openpgp-general%3Ainfosec.exchange