πŸ’Ύ Archived View for rawtext.club β€Ί ~sloum β€Ί geminilist β€Ί 001920.gmi captured on 2020-11-07 at 02:33:26. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

-=-=-=-=-=-=-

<-- back to the mailing list

Fw: Re: Mercury

defdefred defdefred at protonmail.com

Thu Jun 25 21:07:52 BST 2020

- - - - - - - - - - - - - - - - - - - 

sorry list email missing in my reply...

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐On Thursday 25 June 2020 11:16, Sean Conner <sean at conman.org> wrote:

It was thus said that the Great defdefred once stated:
On Thursday 25 June 2020 00:03, Sean Conner sean at conman.org wrote:
How do you safely get my public key?
By asking to you?
By checking on https://keys.openpgp.org/?
By checking on several server on a dedicate page of known public keys?
all of this...
Okay, I'll be replying to several of your messages here because I'm
getting mixed signals here. And then I can answer your questions.
First:
It will also permit surfing at the speed of ligth with instant display of
clicked link... something that is no more existing in the
old-school-too-much dynamic web.
and
Having TLS is better, but it come with a latency cost with the one
connection per request behavior. Freedom is also having the choice.
It seems a primary concern of yours is overhead of establishing a
connection. Well, TCP itself has overhead---three packets (at 40 bytes per)
before the connection is considered "up". Yes, TLS increaases that bit
more, but to say that there will be no latency without TLS is not a good
argument. UDP has no latency, but there are other issues with using it [1].
Continuing ...
Optional PGP signature is enough to provide integrity.
Are you sure that TLS is safe? States are allowing communication they
can't decipher?
and
The fun fact is:
- with TLS, the whole server is using only one certficat and the integrity
of publication rely only on this security and you don't know if it is a
compromised server.
- with PGP signature, each writer using the server have his own certificat
to secure his writing integrity.
and
When you are reading pgp signed document from a server where you own a
defined set of public pgp keys, you don't fear MITM attack (the same way
TLS is secure only with a PKI).
The difference is that external PGP signature are all computed only at
document publication time and not on the fly for each user request.
It also seems you have reservations about the PKI infrastructure, which is
fine, I do too. It seems you really distrust TLS. Okay. But PGP (for GPG
for that matter) isn't the silver bullet you think it is. So let me answer
you questions now.
By asking to you?
Okay.HOW do I get you the public key and ensure you have it correctly?
Yes, it's a public key, so there's no issue with people seeing it, but how
do you know I am the one giving you the key?
The only way I know of to be 100% certain is to exchange keys in person.
By checking on https://keys.openpgp.org/?
I'll throw your own statement back at you: "you don't know if it is a
compromised server." I don't know, and I think you don't know either.
Again, your own words back at you: "Are you sure that TLS is safe? States
are allowing communication they can't decipher?"
By checking on several server on a dedicate page of known public keys?
Reduces the likelyhood of MITM, but still a pain.
The hardest part of cryptography, by far, is key management. There is
still no good way to distribute public keys that aren't subject to various
attacks.
-spc
[1] Namely, you open yourself up to participate in amplified denial of
service attacks. I used to run the QOTD service on UDP, until I
realized I was getting requests from forged IP addresses and sending
data to said forged IP addresses. This is why we can't have nice
things on the Internet. [2]
[2] QUIC. Yes, I know about it. Yes, I don't like it, and it will have
similar issues to TCP. Yeah, yeah, Google says it has 0-connection
overhead, but I don't know how hard it's been attacked yet. And
guess what? That's yet another library dependency for a "simple
client" because QUIC has no support in any kernel I know of, and
probably won't for several years. I also don't trust Google, but
that's my issue.