minipgp6 is happening.

https://codeberg.org/minipgp6/ 🔐🤏

For the past four weeks I've immersed myself in writing an extremely minimal, modern #OpenPGP software stack.

There's still a lot of work ahead, but the current draft code already feels quite exciting.
It's very modular and currently weighs just over 5k LOC (including a small Stateless OpenPGP CLI tool).

I look forward to publishing a first version of the code in the coming weeks 🚀

#rfc9580 #RustLang #PGP

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

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