#rfc9580 — Public Fediverse posts

A new snapshot release of #minipgp6 is now available as v0.0.2:

https://codeberg.org/minipgp6/minipgp6/src/tag/v0.0.2

minipgp6 is a very small implementation of a modern subset of #OpenPGP

Note that the v0.0.x series of minipgp6 releases serve strictly as prototypes.
Once prototyping is complete, the v0.1 series will be written from scratch.

#RFC9580 #RFC9980

I'm getting quite annoyed with the state of #GnuPG as a packager.

Upstream silently keeps releasing 2.2 versions to this day(!) and at the same time claims 2.4 will soon be EOL (also refuses to backport security fixes for it).

Meanwhile, there are no good reasons to upgrade to 2.5, unless one wants incompatibility with the entire rest of the ecosystem (see https://wiki.archlinux.org/index.php?title=GnuPG&oldid=860217#OpenPGP_compatibility).

The move to #OpenPGP #RFC9580 compliant solutions can't happen early enough!
Also, I'm glad we have @freepg

Relax 😎! GPG is not OpenPGP!

Yesterday, vulnerabilities were published https://gpg.fail but they don't affect #deltachat or other #chatmail clients because

A) We never used #gnupg for anything; we use the modern #rustlang #openpgp implementation @rpgp, security audited multiple times.

B) #openpgp is fine, as modernized in #RFC9580, which already warns against several #gpgfail issues (gpg didn't implement that spec)

Please spread the word that #gpg is not #openpgp ... Thanks! #39c3

@Velocifyer @andrewg That's the reason for my plans to switch from #GnuPG to #sequoiapgp, not the #LibrePGP vs #RFC9580 mess. If a RTFM doesn't suffice and it comes down to RTFC (...Code), I am out.

See GnuPG manpage:

❯ gpg --version | head -n 1
gpg (GnuPG) 2.5.13
❯ man gpg | sed -n '/^[[:space:]]*dane/,/^$/p'
              dane   Locate a key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt.

... and:

The lookup result MUST pass DNSSEC validation; if validation reaches any state other than "Secure", the verification MUST be treated as a failure.

Source: https://datatracker.ietf.org/doc/html/draft-ietf-dane-openpgpkey-05#section-5

@mgorny Thanks for planning to bring up my bug (https://bugs.gentoo.org/963069) for discussion in the council. I personally use OpenPGP with all bells and whistles, but agree that what happens lately (#LibrePGP vs #RFC9580) is a s**tshow, and #OpenPGP was never easy to use. When it comes down to it, we should think about what the main use of OpenPGP at Gentoo is. And, that's signing commits if I am not mistaken. If #RFC9580 and #LibrePGP folks can't reach an agreement, I hope that #Git gets some logic implemented that allows it to automatically delegate the task of v5 (LibrePGP) or v6 (RFC9580) signature verification to the correct OpenPGP tool. In that case, users are free to choose the tool of their choice for Git commit signing.

No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.

Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.

Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.

Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.

https://bugs.gentoo.org/963069

Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.

So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.

Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.

So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".

https://bugs.gentoo.org/963069

I just released #PGPainless 2.0!

The new release comes with support for #OpenPGP v6 (#rfc9580) leveraging #BouncyCastle|s new high-level OpenPGP API internally.

The API saw substantial changes compared to the 1.7 release line. Among others, it migrated away from the singleton pattern towards configurable API instances.

You can download the (Linux_x86_64) native CLI binary binary here: https://github.com/pgpainless/pgpainless/releases/tag/2.0.0

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

#rfc2440 #rfc4880 #rfc9580 #librepgp

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

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

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

This release brings support for the updated formats in the new OpenPGP RFC 9580 (including "v6" keys and signatures).

For more on SOP, see https://www.ietf.org/archive/id/draft-dkg-openpgp-stateless-cli-09.html

#OpenPGP #SOP #GnuPG #RFC9580

Un breve post sul mio sito in cui completo con qualche dettaglio in più il mio toot sulla nuova versione di #OpenPGP #RFC9580 di qualche giorno fa

https://www.fabriziotarizzo.org/openpgp-rfc9580/

Principali novità #RFC9580:
- Nuovo formato per chiavi, firme e messaggi
- Fingerprint chiavi più lunga: 64 cifre hex
- Nuovi algoritmi:
* Firma e Cifratura asimmetrica Ed25519 e X25519 (MUST); Ed448 e X448 (SHOULD)
* Cifratura simmetrica AEAD OCB (MUST); EAX e GCM (MAY)
* Memory-hard S2K Argon2
* Hashing SHA3
* Key derivation HKDF
- Firme non deterministiche
- Deprecazione algoritmi obsoleti (RSA<3072, DSA, ElGamal, MD5, SHA1, RIPEMD, IDEA, 3DES)
- Molto altro (RFC 9580 Appendix B)

Dopo ben 9 anni di lavoro è finalmente formalizzata la nuova versione dellio standard #OpenPGP #RFC9580. Le novità sono tante (quasi 200 pagine di specifiche contro le 90 di RFC4880), l'adozione e la transizione saranno presumibilmente processi piuttosto lunghi, anche perché probabilmente molti aspetteranno la RFC definitiva sugli algoritmi post-quantum.

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

Oh great, seems #RFC9580 as the next version (including cryptographic improvements) of #OpenPGP has just been released:

https://datatracker.ietf.org/doc/html/rfc9580

All relevant implementations will soon support this new standard (well, apart from GnuPG and RNP who apparently enjoy the trip into proprietary format land).

#IETF #cryptography #standardization