
Cryptography Dispatches: Hello World, and OpenPGP Is Broken - FiloSottile
https://buttondown.email/cryptography-dispatches/archive/cryptography-dispatches-hello-world-and-openpgp/
======
mbrumlow
Can we stop saying that pgp is busted and just talk about how the keyservers
are the problem with how people decides to exchange keys ?

I don't use key servers. So when I get an encrypted message from my friend I
have no issues.

Allowing a third party such as a key server to play some role in veifiing the
authenticity of a key is basically broken from tht start, and has nothing to
do with pgp it's self.

~~~
edoceo
Isn't keybase.io trying to solve this?

~~~
yarrel
They decided to bolt on sending cryptocurrency to people they haven't
KYC/AML'd instead.

------
xucheng
> At least at some points we need proper transactional behaviour and Sqlite
> implements that by talking a temporary copy of the database - not an option
> for large keyrings.

I don’t understand how GPG maintainers think they can implement something
better (function and performance-wise) than a proper database engine. Also I
don’t think GPG will ever need to handle keyring lager than 140TB [1].

[1]:
[https://www.sqlite.org/whentouse.html](https://www.sqlite.org/whentouse.html)

~~~
mikeash
I’m pretty sure SQLite doesn’t implement transactions that way anyway. That’s
a pretty bad misunderstanding of how it works. I suppose it’s easy to think
you can do better than SQLite if you think SQLite is really bad.

~~~
blattimwind
SQLite never implemented transactions that way, neither in undo nor WAL mode.

Someone might have misunderstood how undo logging / rollback journals work.
Only pages to be changed are recorded in the rollback journal, not the entire
database.

------
Boulth
Very nice article, I'll definitely subscribe!

> For example, it was never clear to me whether signing a key meant that I’d
> verified the person’s identity, or that I then trusted them to verify other
> people’s identities.

Signing means you verified identity. Trust to verify (also called ownertrust)
is controlled by a different setting and you can trust someone to verify other
keys fully or marginally (or not at all if you know someone is controlling
given key but does not verify others well). See this excellent post for
details: [https://www.linux.com/learn/pgp-web-trust-core-concepts-
behi...](https://www.linux.com/learn/pgp-web-trust-core-concepts-behind-
trusted-communication)

~~~
tptacek
I think he understands that in general. The problem is that, in practice, the
"web of trust" depends on significant numbers of users trusting _other_ users
to verify _still other_ users on their behalf, which is in practice something
most people are (or should be) loath to do.

~~~
mikekchar
I think we need to rely on this at some point, though. If my friend Alice
introduces her friend Bob to me, that's my only way of determining that when
Alice is talking about Bob, it's _this_ Bob and not a different Bob.

I actually don't think there is a problem with the concept of a web of trust
per se. It's a fact of life. I think that the software doesn't help you use it
appropriately. Even if Alice says that a person is Bob, I should not be fooled
into thinking that it _really_ is Bob, or that Bob is trustworthy. All it says
is that when Alice talks about "Bob", she means this person who we're calling
"Bob". If "Bob" then introduces me to "Cathy", we shouldn't be fooled into
thinking that it really is Cathy. However, it's still very useful to know that
Cathy is Bob's friend who is Alice's friend. If Alice tells me to talk to
Bob's friend Cathy, I can be totally comfortable talking to the "Cathy" that
Bob introduced me to.

Just to make a more concrete example, imagine that you have a problem with
your software. You contact the company that supplies it and somehow determine
that the person you are contacting is really operating on behalf of the
company. They refer you to second line support. It would be incredibly useful
to know that the second line support person you are talking to is, in fact,
the second line support person you've been directed to and not a man in the
middle. You don't care who that second line support person is. Maybe they
aren't using their real name. Maybe they are an illegal immigrant. None of
that matters to you. All you care is that they are the person you were
directed to. And if they direct you to third line support, you care that the
person you are talking to is the person you were directed to.

People get hung up on the wrong things with PGP IMHO. They check people's
passports and include photos in their keys, etc, etc. I mean, great if you are
the government trying to ascertain if a key really belongs to a citizen, but
completely useless for most practical purposes. _All_ you care about is that
chain.

~~~
tptacek
The kernel of the conceptual problem with this web-of-trust feature is in
another Filippo post[1]: when I sign someone's else's key, it is difficult (in
practice: impossible) to really know the provenance of that key. The signer
could have gotten the key from a keyserver (in which case you now transitively
trust the keyserver). Or they could have gotten it from a random email saying
"this is my new key". You don't know; the basis for trust isn't there, or
rather, to the extent it is, it's only there across strong, short paths in the
graph of key signatures; it doesn't scale out to the whole "web".

[https://blog.filippo.io/giving-up-on-long-term-
pgp/](https://blog.filippo.io/giving-up-on-long-term-pgp/)

~~~
mikekchar
I'm definitely not arguing against that. I think keyservers are one of the
worst things to ever happen. PGP's _implementation_ of the web of trust is
hugely flawed. I'm saying the concept is still incredibly useful. I get
frustrated when I see suggestions that we should abandon the notion signing
other people's keys because users can't be trusted to do it properly.

I think the author of the article you link to is mostly right. Long term keys
don't make much sense most of the time. A key that's signed by a million
people is useless. I only care that it's singed by the people who are relevant
in the context for which I'm using it. Relationships change too. If I've got a
key from level 1 support to a level 2 support person, I can't trust 6 months
later that the level 2 support person still works at the company. You need to
have a context to describe the link in order to understand it. PGP (and by
extension GPG) are absolutely horrible in that regard.

I find it ironic that the author says that the best way to reach them is by
their Whisper number. _This_ is what frustrates me. We exchange "horribly
flawed implementation" for a central trust broker -- who may or may not be
trust worthy.

~~~
fiter
This is a very useful way to think about a/the web of trust. Thank you; I am
sure I will use it later.

------
gregmorton
Every two other week, someone writes that openGPG is broken. Guess what they
want to say is that if you use PGP in certain ways, it's broken (keyservers,
addons like enigmail and so on). But nobody has ever been able to demonstrate
that it's broken if you use it correctly. I'll stick with openGPG.

~~~
FAKEDETECTOR
Is that a fork of openPGP or some other product that is based on the same
specs? I could not find anything meaningful for openGPG.

~~~
chaosite
That's because it doesn't have open in its name, it's called GPG or GnuPG.

It's another product based on the same specs.

[https://en.wikipedia.org/wiki/GNU_Privacy_Guard](https://en.wikipedia.org/wiki/GNU_Privacy_Guard)

------
tptacek
To be clear: this is a subhed from Filippo's email newsletter (which you
should subscribe to), relating a news item about the ridiculous SKS/GnuPG-key-
handling fiasco from last week; it is not a comprehensive summary of all the
ways in which OpenPGP is broken, despite the title.

~~~
inflatableDodo
>it is not a comprehensive summary of all the ways in which OpenPGP is broken

Is there a comprehensive summary anywhere?

~~~
Perceptes
This article by the same author is perhaps not comprehensive, but a good place
to start: [https://blog.filippo.io/giving-up-on-long-term-
pgp/](https://blog.filippo.io/giving-up-on-long-term-pgp/)

~~~
pferde
Except that the article is only about one particular reason the author finds
PGP use uncomfortable. It doesn't deal with any "brokenness of PGP" at all.

------
kingishb
Just wanted to say thanks for making the awesome cryptography newsletter!
Really enjoyed reading this.

------
Lowkeyloki
I've seen the link from this article before about alternatives to PGP and it
bugs me for two reasons. One is the implication that everyone should write all
software in Go. The other is that when you swap out one system for half a
dozen, you now need to identify yourself half a dozen different ways. That
seems confusing.

------
eadmund
> I don’t believe in invasive tracking

And yet, I see 'utm_source=cryptography-dispatches' in the URLs!

~~~
hydrox24
It is tracking, but it is not invasive.

------
luizfelberti
I've mostly been able to avoid PGP, but one workflow that I haven't been able
to find a decent alternative for it Git commit signing.

Does anyone know good alternatives in this space?

~~~
tuxxy
Linus himself has expressed his opinion several times that signing every
commit is useless. His posts here explain it a bit:
[http://git.661346.n2.nabble.com/GPG-signing-for-git-
commit-t...](http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-
td2582986.html)

~~~
luizfelberti
Well yes, signing _every_ commit is useless. He did not however, at any point
during that exchange, express the idea that commit signing is a useless
activity. And that is what I was referring to.

Currently Git seems to be very much integrated with GnuPG and the same goes
for GitHub's UX sprinkles over the signing feature. That is what I'd like a
decent alternative to.

I considered using OpenBSD's signify but it does not integrate as nicely as
GnuPG signing so I'd basically be rolling my own mechanism (which is fine I
guess, but feels subpar)

~~~
Boulth
For the record git signing can also use X.509 certificates but from what I see
it's still managed by GnuPG.

