POV-Ray : Newsgroups : povray.off-topic : PGP is hard Server Time
1 Nov 2024 11:17:06 EDT (-0400)
  PGP is hard (Message 1 to 3 of 3)  
From: Orchid Win7 v1
Subject: PGP is hard
Date: 13 Jul 2013 11:49:46
Message: <51e1771a$1@news.povray.org>
You may or may not find this interesting:

http://reports-archive.adm.cs.cmu.edu/anon/1998/CMU-CS-98-155.pdf


Post a reply to this message

From: Orchid Win7 v1
Subject: Re: PGP is hard
Date: 13 Jul 2013 12:46:24
Message: <51e18460@news.povray.org>
On 13/07/2013 04:49 PM, Orchid Win7 v1 wrote:
> You may or may not find this interesting:
>
> http://reports-archive.adm.cs.cmu.edu/anon/1998/CMU-CS-98-155.pdf

Hmm, that's a fairly small sample size. But it's interesting; I sit here 
thinking that PGP is easy. And then they list the points that a user of 
the system has to realise, and suddenly you see how awfully non-obvious 
most of this stuff actually is.

They focus exclusively on sending email with PGP. So, if I install PGP 
and want to send an encrypted email, I need to:

* Realise that I need the recipient's PGP public key.

* Figure out how to obtain that.

* Work out how to import it to my keyring.

* Find the button to encrypt my email.

* Hit send.

If I want to sign as well, I additionally need to:

* Know what the hell a signature even is, and why that's useful.

* Realise that I need to generate a keypair in order to sign anything.

* Comprehend that the guy at the other end needs my public key in order 
for the signature to do any good.

* Figure out how to send my public key.

* Find the button to sign my email.

That's... actually fairly hard, TBH. We're expecting the user to figure 
out quite a lot of simple but non-obvious stuff here. Oh, I mean sure, 
if you sit down and read the huge tome of a manual that PGP comes with, 
you should know all this.

I personally remember installing PGP for the first time, and being 
baffled by the key management window. I mean, WTF? I just created one 
keypair, so why is there so much stuff in here? And what does it all 
mean? (So much for being a computer expert!)

Now try even attempting to explain to our clueless user the problems of 
key forgery. I mean, I can generate a keypair and write ANY NAME I LIKE 
on it. If you go to a server and find six keys with my name on them, 
which one is the real one? The one with four signatures on it? Oh, but 
wait, those are from fake keys are well. Welcome to the rabbit hole!



Come with my on this journey for a moment. When I connect to a server 
secured with HTTPS, all this stuff "just works". I don't have to know or 
care about all this PKS stuff. I just click a button, and the connection 
is automatically encrypted. Why can't email work like that?

In part, this is because as a web server, I'm not the guy who spent 
three days trying to figure out how to install the certificate on the 
web server correctly. Some highly-paid IT expert did that. As an 
end-user, I don't need to care.

But, like I said, come on a journey with me. To connect to a web server, 
all you need is a URL. To send an email, all you need is an email 
address. PGP keys typically have email addresses on them. What if, 
hypothetically, we extended the SMTP protocol such that it were possible 
to query a user's PGP key just by knowing their email address? Like, if 
you could sent a specially-formatted email which causes the mail server 
at the other end to immediately email back the key? Now imagine that the 
mere act of typing in a person's email address automatically fetches 
their public key, and encrypts the message with that.

If email could work like this, everybody would be using encryption. 
Think about it; PGP has existed for decades, it costs nothing, and I've 
never met a human IRL who's actually heard of it. I've also never met a 
human IRL who's heard of TLS either, yet everybody uses that on a nearly 
daily basis. Nobody uses PGP because it's too complicated.

Now, setting up the mapping from your email address to your key in the 
first place? THAT could be problematic... First because the user has to 
figure it out, second because if someone can insert a fake key their and 
intercept mail, we have a man-in-the-middle attack. Also, for some 
reason it is not usual for a mail client to connect directly to the 
destination mail server in the way a web browser connects to a web 
server. This complicates key lookup.

It still strikes me that this stuff could be a lot simpler than it is. 
But then, not everybody uses PGP. Some people like TrueCrypt, some 
people use something else entirely. Automatic key discovery wouldn't be 
useful unless everybody was using the same encryption technology, and 
that can only happen if one lucky product gets embedded in the standard 
document. Not likely.



In other news, this morning I set out to write a PGP parser, and instead 
spent several hours nerding out over how cool PKS is, without actually 
writing much code. :-/


Post a reply to this message

From: Le Forgeron
Subject: Re: PGP is hard
Date: 13 Jul 2013 14:30:47
Message: <51e19cd7$1@news.povray.org>
That's why there is public key server, and pgp/gpg got a slow adoption:
the model is the web of trust (A knows from direct encounter that the
key of B is ok, and sign & trust it. J knows from direct encounter that
the key of A is ok and sign & trust it. and so on)

The nice point, if everyone would have public key, is that the
generalisation of Erdos Number would be very low.
(If you have a letter to transmit to Obama (or anyone else), from hand
to hand using only directly know people, it is assumed to be something
as low as 7 (assuming everyone is ready to cooperate and not put in in
the bin))

Signing & trusting a key is something that should not be handled lightly.

The alternative to the web of trust is the current implementation of
certificates (used in all new Microsoft code for 64 bits at driver
level). Alas, central agencies have demonstrated that they are weak
points. (compromised private keys or stolen... oh well, nobody cares...
keep the money flowing!)


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.