The IETF working group that I co-chair, PQUIP, had its first RFC published today. RFC 9794, "Terminology for Post-Quantum Traditional Hybrid Schemes", lists and describes terms used in post-quantum cryptography that are specific to the hybrid schemes that have become the focus for much of the PQC development work.

In short hybrid schemes are those that fully mix both post-quantum and traditional asymmetric algorithms. There are a lot of ways to mix them (some better than others), and thus there are a lot of properties that different mixtures have. The result is a lot of potentially confusing vocabulary full of similar-looking four-word chains. This document lays out all the differences so that other groups (other IETF working groups, other standards development organizations, governments making standards, ...) can be precise about what schemes they are adopting and why.

Congrats to the WG and the RFC authors!

https://datatracker.ietf.org/doc/rfc9794/

#ietf #rfc #pqc
(not using hashtag-hybrid because this ain't about cars, and certainly not using hashtag-crypto because bleaugh)

First steps towards more robust sync!

#Hockeypuck’s dataset normalisation rules (or “filters”) were updated between v2.1 and v2.2, meaning that #SKS recon did not work between #openpgp #keyservers running the older and newer versions. The keyservers could not all be updated simultaneously, and a few keyservers still run v2.1 today for compatibility reasons, so we had to find a way to prevent the network from split-braining.

The quick and dirty solution was a small script that runs on each side of the filter discontinuity, polls for local changes, and submits them to the other side over HKP (the protocol your #PGP client uses). But this is effectively the same idea as the old PKS sync model, just over HTTP(S) instead of email. And sks-keyserver used to support PKS-over-email, so shouldn’t hockeypuck be able to do PKS-over-HTTP natively?

The short answer is, it can! It was long intended for hockeypuck to support PKS email, but only a fraction of the necessary code was written, and there were no tests. Today, the pgpkeys test swarm has just performed its first sync using the completed PKS code, which supports *both* HTTP and email transport.

It’s not ready for production yet though. Further testing is required, and then the second part of the PKS code can be written: automatic failover from SKS to PKS when filter mismatch is detected (and just as importantly, automatic fail*back*).

This will mean that keyserver operators will be able in the future to upgrade across filter discontinuities without risking a split brain scenario. It should also mean that key updates submitted to the hockeypuck network could be automatically synced to @keys_openpgp_org … watch this space! 😎

(Hockeypuck v2.3 development is kindly supported by @NGIZero Core)

First steps towards more robust sync!

#Hockeypuck’s dataset normalisation rules (or “filters”) were updated between v2.1 and v2.2, meaning that #SKS recon did not work between #openpgp #keyservers running the older and newer versions. The keyservers could not all be updated simultaneously, and a few keyservers still run v2.1 today for compatibility reasons, so we had to find a way to prevent the network from split-braining.

The quick and dirty solution was a small script that runs on each side of the filter discontinuity, polls for local changes, and submits them to the other side over HKP (the protocol your #PGP client uses). But this is effectively the same idea as the old PKS sync model, just over HTTP(S) instead of email. And sks-keyserver used to support PKS-over-email, so shouldn’t hockeypuck be able to do PKS-over-HTTP natively?

The short answer is, it can! It was long intended for hockeypuck to support PKS email, but only a fraction of the necessary code was written, and there were no tests. Today, the pgpkeys test swarm has just performed its first sync using the completed PKS code, which supports *both* HTTP and email transport.

It’s not ready for production yet though. Further testing is required, and then the second part of the PKS code can be written: automatic failover from SKS to PKS when filter mismatch is detected (and just as importantly, automatic fail*back*).

This will mean that keyserver operators will be able in the future to upgrade across filter discontinuities without risking a split brain scenario. It should also mean that key updates submitted to the hockeypuck network could be automatically synced to @keys_openpgp_org … watch this space! 😎

(Hockeypuck v2.3 development is kindly supported by @NGIZero Core)

CISA have, at the last minute, extended the MITRE CVE contract. “The CVE Program is invaluable to cyber community and a priority of CISA. Last night, CISA executed the option period on the contract to ensure there will be no lapse in critical CVE services. We appreciate our partners’ and stakeholders’ patience.” HT @metacurity

It’s unclear how long it has been extended for.

Huge congrats to the folks behind the new CVE Foundation (https://www.thecvefoundation.org/) - amazing work to be able to announce this so quickly after the news about MITRE's funding expiring broke. I really look forward to see how the next phase of the CVE Program will unfold... I hope lots of private sector and government folks are having conversations about how they can support the Foundation going forward.

@circl and by the way, we just launched 🔗 https://gcve.eu/

GCVE: Global CVE Allocation System

The Global CVE (GCVE) allocation system is a new, decentralized approach to vulnerability identification and numbering, designed to improve flexibility, scalability, and autonomy for participating entities.

While remaining compatible with the traditional CVE system, GCVE introduces GCVE Numbering Authorities (GNAs). GNAs are independent entities that can allocate identifiers without relying on a centralised block distribution system or rigid policy enforcement.

Mastodon account for GCVE - @gcve

Dear Fedi friends. I want to make a short #survey to understand who actively uses #keyservers today. I am interested in understanding the meaning and the value that people attribute to keyservers nowadays, and the shift in perceptions of email #encryption 🔑🔒

📊 I will be making several polls (follow the thread!)

💌 I also would be happy if some of you agree to talk with me more in depth over an e2ee encrypted channel of your choice, no need to make a call, just messages are enough

👾 Feel free to share the polls and reach out in comments if you can and want to be part of this study.

👩🏽‍🎓 If this ever leads to any kind of publication, I will be following the standard ethical protocol adopted in the academic research community, which is to 1. ask informed consent for quoting; 2. quoting anonymously by default, unless the person wants to be named and 3. right to withdraw from the study even after responding to the questions

QUESTION 1: DO YOU USE KEYSERVERS?

(New blog) The Principles of User-Friendly Cryptography

Cryptography has a well-deserved reputation for being unfriendly, even hostile, to non-experts. The most successful applications of cryptography therefore attempt to hide the gory details from the end user as far as possible. But there is no such thing as a leak-proof abstraction, and the existence of cryptography will inevitably become apparent. It is the responsibility of the application developer to ensure that the unpleasantness is kept to a minimum.

https://blog.pgpkeys.eu/user-friendly.html

(New blog) #OpenPGP Stack Layering

The OpenPGP application stack can be roughly considered to be divided into layers. These layers have no official meaning, and are somewhat fluid. They are however useful as a mental model, particularly when defining extensions to OpenPGP.

RFC9580 fully specifies only layers 2a, 2b, and 2f.

https://blog.pgpkeys.eu/stack-layers.html

We are pleased to announce the release of Hockeypuck 2.2.3. This is a bugfix release to fix several minor issues:

* Stats now also served on /pks/stats
* HEAD and OPTIONS methods now supported
* Algorithm names now displayed correctly
* Fixed stats calculation
* Updated to protonmail/go-crypto v1.1.3

Various improvements have also been made to the docker-compose tooling.

Note that there is one cosmetic breaking change IFF custom templates are being used. Release notes can be found at https://github.com/hockeypuck/hockeypuck/releases/tag/2.2.3

----

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

Hockeypuck 2.2.x is a significant upgrade that includes the following changes:

# Features

• Fully stable sync
• Improved multithreading safety
• Deletion of personal data from hard-revoked keys
• Admin deletion of keys via signed submissions
• Detached revocation certificate support

# Deprecations

• SKS-keyserver recon compatibility
• UAT image packets
• User deletion and replacement of keys via `/pks/delete` and `/pks/replace` endpoints

More information: https://github.com/hockeypuck/hockeypuck/wiki

(New blog) Analysis of OpenPGP Reserved Code Points

There are quite a few code points in the IANA OpenPGP registries that are marked “Reserved” with little or no explanation.

Some code points are reserved for future use and MAY presumably be un-reserved. Others are reserved to avoid incompatibility with deprecated or experimental features. Some have been reserved for speculative features that were never implemented.

This blog attempts to reconstruct the rationale for each of the reserved code points.

https://blog.pgpkeys.eu/reservations.html

In two weeks, we're going to release version 1.0 of sq. With this version we're also stabilizing our CLI. So, if you have any feedback on how we name commands and arguments, or their semantics, please create an issue soon.

#pgp

https://gitlab.com/sequoia-pgp/sequoia-sq

Are you interested in enshittification-resistant application development?

After almost two years of collaboration with the wonderful @n0iroh team, we are happy to announce that #deltachat 1.48 apps on all platforms contain top-notch Peer-to-Peer networking support, including hole-punching and forward-secret end-to-end encryption. It is exposed through the new #webxdc realtime APIs and there are some nice initial showcase apps 🎉

https://delta.chat/en/2024-11-20-webxdc-realtime

Le slide dell’intervento “(Open|Libre)PGP - Novità, controversie e sviluppi futuri” proposto ad HackЯocchio 2024

https://www.fabriziotarizzo.org/documenti/slide-openpgp-2024/

#OpenPGP #LibrePGP #RFC9580 #hackrocchio

Saying "Don't use PGP, use SigStore or Age!" is the same class of dumb as saying "Don't use web standards, use Flash or Java embeds!".

Before advocating everyone abandon standards and use whatever tools have the better UX or defaults for your use case blindly, maybe take the time to actually understand the problems the standards are trying to solve for, and if any improvements or better implementations are in progress.

Back in May or so I sat down with the Linux #Inlaws to talk about PGP and GnuPG things. That has now been published in season 2, episode 22, see https://linuxinlaws.eu/#episodes

https://archive.org/download/LI_S02E22_OpenPGP__7525/LI_S02E22_OpenPGP_.mp3

Now, discussion about a mechanism for a smooth key rollover / replacement in #OpenPGP .

For instance, should we add a reference in the format to "preferred key server to fetch the new key"?

#IETF121

Show of hands at #IETF121: "People are vigourously without an opinion".

Post-Quantum Cryptography in OpenPGP - an IETF draft

#openpgp #pgp #postquantum

🔗 https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/

The final agenda for the #IETF121 Dublin meeting hosted by Cisco is now available! Register, and find details about 100+ sessions, the #IETFHackathon & more: https://www.ietf.org/meeting/121/