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)

@Xeniax Totally nerdsniped :D I'd love to be a part of the study.

I don't think that #KeyServers are dead. I think they evolved into Verifying Key Servers (VKS), like the one run by a few folks from the OpenPGP ecosystem at https://keys.openpgp.org/about . More generally, I believe that #PGP / #GPG / #OpenPGP retains important use-cases where accountability is prioritized, as contrasted with ecosystems (like #Matrix, #SignalMessenger) where deniability (and Perfect Forward Secrecy generally) is prioritized. Further, PGP can still serve to bootstrap those other ecosystems by way of signature notations (see the #KeyOxide project).

Ultimately, the needs of asynchronous and synchronous cryptographic systems are, at certain design points, mutually exclusive (in my amateur estimation, anyway). I don't think that implies that email encryption is somehow a dead-end or pointless. Email merely, by virtue of being an asynchronous protocol, cannot meaningfully offer PFS (or can it? Some smart people over at crypto.stackexchange.com seem to think there might be papers floating around that can get at it: https://crypto.stackexchange.com/questions/9268/is-asynchronous-perfect-forward-secrecy-possible).

To me, the killer feature of PGP is actually not encryption per se. It's certification, signatures, and authentication/authorization. I'm more concerned with "so-and-so definitely said/attested to this" than "i need to keep what so-and-so said strictly private/confidential forever and ever." What smaller countries like Croatia have done with #PKI leaves me green with envy.

#survey #keyservers #pgp #encryption

PART 3 OF THE KEYSERVER STUDY

(see Part 1 here: https://mastodon.ml/@Xeniax/114273355035626553)

❓QUESTION 3: WHY HAVE YOU STOPPED USING KEYSERVERS

#survey #keyservers

🔒🔑 PART 2 of the Keyservers Study
(see part 1 here: https://mastodon.ml/@Xeniax/114273355035626553)

❓QUESTION 2: HOW DO YOU MAINLY USE KEYSERVERS?

✨✨ if you have used them in the past, you can also answer here!

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 State of the Keyservers in 2024

“In the two and a half years since the sks-keyservers.net shutdown in June 2021, the concept of #OpenPGP #keyservers has been called into question. However, keyservers still provide a vital service to the OpenPGP ecosystem.
…
OpenPGP is one of only two widely-used cryptography standards to include a full Public Key Infrastructure”

https://blog.pgpkeys.eu/state-keyservers-2024.html

@DrPen
Yes, #Tor is good but in some ways #I2P is better.

We would like #universities to not only run Tor and I2P relays but they should also provide #keyservers, code repositories, mid-scale #internetArchives, jump services (a sort of DNS for I2P).

We need to return to a world where universities don't just pander to the corporate world for #funding also.

Maybe we cannot get there.

TIL the protocol everyone uses for #OpenPGP #keyservers appears to be documented only in an Internet Draft that expired about 20 years ago. Why did it never become an RFC if not an STD? Is it hiding in some hard-to-find RFC, or more-stably documented in some non-IETF place?

Just when I thought that I couldn’t possibly be more disappointed by #Python's tooling and environment, now #PyPI is no longer supporting #OpenPGP signatures: blog.pypi.org/posts/2023-05-23…

Their rationale for doing so is one of the stupidest things I‘ve ever read about OpenPGP — and I’ve read a lot of stupid takes about OpenPGP over the years!

It basically boils down to two points:

1) One-third of the public keys used “were not discoverable on major public #keyservers, making it difficult or impossible to meaningfully verify those signatures”.

2) Half of the other keys “were unable to be meaningfully verified at the time of the audit“.

On the first point: just because you can‘t find a key on keyservers doesn‘t mean the key can’t be used. Keyservers have never been the one and only way to distribute keys. Actually, the OpenPGP world has been moving away from keyservers for several years already, and most keyservers are slowly dying. The keyserver from the Sequoia-PGP folks is one of the few exceptions.

On the second point: WTF? Just because you were unable to verify to “meaningfully verify” a key doesn’t mean anything! The validity of an OpenPGP key is not something absolute that can be verified by an auditor and then held true for everybody. The entire point of OpenPGP, compared to the X.509 world, is that it is up to each individual user to verify the validity of keys (possibly using the #web-of-trust, but that’s not the only way, and actually, as for the keyservers, the OpenPGP world has been moving away from the WoT). A key that is unverified for Alice may very well be perfectly valid for Bob.

@dcent
We are not seeing the other half? Only this post.

1) Sounds good.

2) There's no point talking to a bank about investments and loans if communications are leaky. Imagine communicating re a possible #homeLoan and Google/M$/Blackrock, seeing that an using that info against you.

We need secure comms. Therefore banks should use/store ppl's public encryption keys. They need to act as a #keyserver also, because a) there's not enough good #keyservers, b) also stops ppl knowing where yu #bank.

For reference (see above toot and child-toots of above toot) #banksAsKeyStores #banks #keyStores #keyservers #reinventBanks #localConnections #makeBanksBetter #realJobs #eepsites #decentralisation #certificateAuthorities #localJobs

@flabbonix @Ludo

3/3
g) making #banks better (see #keyservers),
h) ensuring that #privacy and #sovereignty remain #humanRights, and that such rights extend to our devices.

@vidak
New idea for a #song.

"I wanna talk to you,
I had to write something,
But its that time again,
When all the #keyservers are dowwwn

(Down Down Down Oouu Oouu Oouu)"

#techSong #skit #funny #GPG #pgp #fediLyrics

with #keyservers pubkey, setup remote keyring:
gpg -K --keyid-format long | grep '\[SC\]' | grep -v expired | sed 's#sec \+[^/]\+/\([0-9A-F]\+\).*#\1#' | ssh user@target 'xargs -n 1 gpg --recv-key'
for automatic #socket name :

Well there's been a lot of frenetic discussion and misunderstandings about the latest SPAMming of the #SKS #keyservers recently.

It's going to get bad before it gets worse lol. The article I've linked to has some really divisive points - I'm not posting it to start a debate, but
the two parts that even a neophyte should pay attention to in the article are - use #Signal and #Magic_Wormhole.

I hope that helps!

https://bit.ly/2JC8N9B

https://youtu.be/oFrTqQw0_3c

#FOSS #encryption #privacy