Nobody uses encrypted email, because it is too awkward.
On 9/7/19 2:41 AM, Hans-Georg Michna wrote:
Nobody uses encrypted email, because it is too awkward.
Your subject is false. I and a double digit number of people I know use >encrypted email (S/MIME or PGP) daily.
You will probably have to admit that you exchange emails with
lots of people who don't use encrypted email, because it is too
awkward.
Of course the subject is false. It oversimplifies or, in this case, exaggerates, but that's what very short statements do.
But how about the idea behind it?
You will probably have to admit that you exchange emails with lots
of people who don't use encrypted email,…
…because it is too awkward.
As a lay user, yes, I agree it's difficult to deal with cryptography.
Just having to *keep* a private key is a problem. We're always losing
our passwords. (In fact, passwords are a pain and so are keys.)
As a user, though, let me share an idea. Consider two people A and
B and e-mail clients, cA and cB. A wants to exchange some e-mails
with B. So A writes up his message and mails it to B. cA will not
send the message itself to B just to yet. That first e-mail message
will only initiate a protocol to exchange public keys. If B accepts,
more mail messages go back and forth until the protocol reaches its
desired state, ready for exchanging encrypted data. (This can take
days depending how often A, B check their e-mails. It could take
seconds if both are online at the same time.) Until this happens, cA
and cB handle everything. A, B do nothing. The most they can do is
take a look at message status in their clients to see in what phase
the protocol. cA has kept the message locally until cB sends B's
public key which could be generated just for that e-mail thread, say.
Now, cA and cB know each other and communication takes place without
users having to do anything about keys and whatnot. cA and cB could
be set up to use a key at every message (slow), per thread (faster)
or even always use the same key with everyone they talk to.
All of this seems obvious. I'm not aware of any client doing it this
way, though. Suppose one of these very popular e-mail clients begin
to do this by default. ``Everyone'' would start using it overnight
without even knowing what's going on.
Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> writes:
[...]
As a user, though, let me share an idea. Consider two people A and B
and e-mail clients, cA and cB. A wants to exchange some e-mails with B.
So A writes up his message and mails it to B. cA will not send the
message itself to B just to yet. That first e-mail message will only >initiate a protocol to exchange public keys. If B accepts, more mail >messages go back and forth until the protocol reaches its desired state, >ready for exchanging encrypted data. (This can take days depending how
often A, B check their e-mails. It could take seconds if both are
online at the same time.) Until this happens, cA and cB handle
everything. A, B do nothing. The most they can do is take a look at
message status in their clients to see in what phase the protocol. cA
has kept the message locally until cB sends B's public key which could
be generated just for that e-mail thread, say.
Now, cA and cB know each other and communication takes place without
users having to do anything about keys and whatnot. cA and cB could be
set up to use a key at every message (slow), per thread (faster) or even >always use the same key with everyone they talk to.
All of this seems obvious. I'm not aware of any client doing it this
way, though. Suppose one of these very popular e-mail clients begin to
do this by default. ``Everyone'' would start using it overnight without
even knowing what's going on.
On 9/8/19 9:16 AM, Louis Valence wrote:
As a lay user, yes, I agree it's difficult to deal with
cryptography. Just having to *keep* a private key is a problem.
We're always losing our passwords. (In fact, passwords are a pain
and so are keys.)
I'm of the opinion that users are, and have to be, responsible for
something.
As a user, though, let me share an idea. Consider two people A and
B and e-mail clients, cA and cB. A wants to exchange some e-mails
with B. So A writes up his message and mails it to B. cA will not
send the message itself to B just to yet. That first e-mail message
will only initiate a protocol to exchange public keys. If B
accepts, more mail messages go back and forth until the protocol
reaches its desired state, ready for exchanging encrypted data.
(This can take days depending how often A, B check their e-mails.
It could take seconds if both are online at the same time.) Until
this happens, cA and cB handle everything. A, B do nothing. The
most they can do is take a look at message status in their clients
to see in what phase the protocol. cA has kept the message locally
until cB sends B's public key which could be generated just for that
e-mail thread, say.
My experience with S/MIME is somewhat like that. A / cA sends a
/signed/ email to B / cB. cB then extracts what is necessary to
encrypt messages to A. When B / cB sends a /signed/ (and possibly
encrypted) message (back) to A, A / cA then extracts what is necessary
to encrypt messages to B. One /signed/ email each way and both
parties have what is necessary to send signed and / or encrypted
emails between each other.
All of this seems obvious. I'm not aware of any client doing it
this way, though. Suppose one of these very popular e-mail clients
begin to do this by default. ``Everyone'' would start using it
overnight without even knowing what's going on.
No, it couldn't happen overnight. Keys / certificates / et al. must
be acquired from somewhere. This takes some upfront configuration of
the client.
Interesting! I didn't know about S/MIME. I'll read RFC 3369.
Please educate me on this.
Why do we need certificates for the context of A, B communicating
directly?
It's not clear to me but I sense certificates might be involved
to protect A and B from a middle man C.
If C can tamper A and B's communication, then on the first signed
e-mail from A to B (which including A's public key), C could replace
the public key, then B would encrypt B's reply with C's public key,
then C would decrypt the message and reencrypt it back to A using
A's public key --- and A and B would never notice anything wrong.
Even if this is right, it's not clear to me how certificates solve
this problem, so do share your knowledge, if you would.
Thanks!You're welcome.
On 9/11/19 6:31 AM, Louis Valence wrote:
Interesting! I didn't know about S/MIME. I'll read RFC 3369.
Read RFC 3369, et al., if you want to. But I'd suggest avoiding the
murky details of S/MIME, and PGP, for your health. I think a good
tutorial would be a much better introduction. It's a you (likely)
can't see the forest (larger S/MIME ecosystem) because of all the
trees (murky details) getting in the way.
It's not clear to me but I sense certificates might be involved to
protect A and B from a middle man C.
It's more the encryption that protects A & B from the middle man C.
But the encryption uses the keys from the certificates.
If C can tamper A and B's communication, then on the first signed
e-mail from A to B (which including A's public key), C could replace
the public key, then B would encrypt B's reply with C's public key,
then C would decrypt the message and reencrypt it back to A using
A's public key --- and A and B would never notice anything wrong.
That theoretically could happen.
Even if this is right, it's not clear to me how certificates solve
this problem, so do share your knowledge, if you would.
Certificates are (normally) issued by Certificate Authorities, which
are ideally trusted. So, a CA will issue a certificate for A
containing A's pertinent details, notably A's email address. Likewise
a CA will issue a certificate for B containing B's pertinent details.
So, when B receives a signed message from A, B can check details of
the signature, including which CA issues the certificate. A can do
likewise. A and B can (and ideally should) communicate through
different channels to share details of their certificate and validate
some details of the other certificate.
Thus, B can trust the signature on the email from A, and A can trust
the signature on an email from B.
Once the trust is established, it's largely smooth sailing until it's
time to renew certificates.
At least that's my understanding at a high level.
Yes, RFC 3369 is more interested in defining the syntax of the data
to be exchanged. So I dropped it.
From what you say I get the impression that public keys are somehow
embedded in certificates. Is that really the case?
the general assumption that one can safely get the public key from
a Certificate Authority. How can I safely get such thing?
I don't think I've done anything on my computer in a safe way at all.
the general assumption that one can safely get the public key from a
Certificate Authority. How can I safely get such thing?
The CAs that I've used never had the private key. Rather, my web
browser generated the key pair along with a Certificate Signing
Request. The CSR was sent to the CA for them to sign. The CA never
had anything to loose or distrust.
The CAs that I've used never had the private key. Rather, my web
browser generated the key pair along with a Certificate Signing
Request. The CSR was sent to the CA for them to sign. The CA never
had anything to loose or distrust.
I'm lost here. Did you say ``private key''?
I can't ``parse'' the first sentence. I can't understand the rest
of the paragraph either.
What is a CSR and did you send a CA one?
With what purpose?
(How did you know the CA was really the CA you wanted to talk to?)
On 9/13/19 11:21 AM, Louis Valence wrote:
The CAs that I've used never had the private key. Rather, my web
browser generated the key pair along with a Certificate Signing
Request. The CSR was sent to the CA for them to sign. The CA never
had anything to loose or distrust.
I'm lost here. Did you say ``private key''?
Yes.
X.509 certificates are a key pair, public and private, with some
additional metadata.
"The CAs that I've used never had the private key."
My web browser generated the public / private key pair, and then
subsequently sent the /public/ key with some metadata to the CA. That
is largely what a Certificate Signing Request is.
The CA signed my CSR with their private key, thus turning it into a
signed certificate, which they sent back to me.
Notice how the CA never had the private key.
I can't ``parse'' the first sentence. I can't understand the rest
of the paragraph either.
Did that help?
What is a CSR and did you send a CA one?
A CSR is a what a certificate is created from.
With what purpose?
To send transport my public key and metadata to the CA for them to sign.
Once I received the certificate from the CA, I can extract other
metadata and use the CA's well known /public/ key to validate the hash
that they added to the certificate. This allows me to mathematically validate that the CA was who signed it.
I think it largely doesn't matter if there was someone else in between
the the CA and myself. I say this because there was nothing that the intermediate could have done that would cause problems. They could
not modify my CSR because it was signed with my private key. So any certificate I received based on a modified CSR would fail to validate
with my private key. Similarly, things would fail to validate if the intermediary tried to modify the certificate on it's way back to
me. I'm also not worried if the intermediary keeps a copy of the
certificate because it's effectively useless and a waste of bytes on
disk without my private key. (Remember, my private key never left my system.)
So, an intermediary could at most prevent me from getting a functional certificate, thereby performing a Denial of Service. But that would
be easy to detect nearly instantaneously.
A little. Let's see a bit further.
Why should you want your own public key signed by a CA?
The ``hash'' is the signature the CA added. To validate the signature
you need the CA's public key, but it is the CA itself that's giving you
its public key. I think in your description, your communication with
the CA is assumed to be safe and the identity of CA is also assumed to
be correct. (See below for a clearer presentation of this point of
view.)
Here's what I think. Suppose C is a middle-man. (For instance, your
ISP.) Before you establish a TLS session with your CA, to send your CSR
or whatever, C directs you to a different CA, with whom you establish a
TLS session and proceed. C doesn't need to modify your CSR; it only
needs to put a different CA to talk to you. You can only detect such identity-violation if you already have the CA's public key with which
you can verify their signature. So you need to safely get the CA's
public key. How would get such thing safely?
Why should you want your own public key signed by a CA?
Because I want a recipient that doesn't trust me, by (hypothetically)
does trust a public CA. So if said public CA vouches for me, then (hopefully) the recipient will trust the CA's trust in me and thus
trust me themselves. (Think commutative property in math.)
Here's what I think. Suppose C is a middle-man. (For instance, your
ISP.) Before you establish a TLS session with your CA, to send your CSR
or whatever, C directs you to a different CA, with whom you establish a
TLS session and proceed. C doesn't need to modify your CSR; it only
needs to put a different CA to talk to you. You can only detect such
identity-violation if you already have the CA's public key with which
you can verify their signature. So you need to safely get the CA's
public key. How would get such thing safely?
First, the TLS connection with the CA is established before sending
the CSR to them.
Second, most OSs come with public keys of many (hypothetically)
trusted / well known public CAs. These public keys in this OS's (or application's) public key store are what are used to validate
signatures (hashes) from the CAs.
Got ya.
I understand. We have to assume the TLS connection is safe.
But I can't see a method to be safe if you don't assume your ISP is
after you, say. They'd easily make you to talk to an impostor CA and
you'd only detect if the public key of your CA was given to you safely.
(If you downloaded your browser or your OS by way of your ISP, then
your entire security rests on you trusting your ISP.)
My browser was downloaded from the Internet, so my ISP could've easily
given me an impostor browser with impostor public keys and CA
certificates.
My OS has been updated so many times (against my will), I have noYou do have some say. The opportunity cost is high enough that most
say what goes on in here.
On 9/22/19 8:48 PM, Louis Valence wrote:
Got ya.
:-)
I understand. We have to assume the TLS connection is safe.
No, we don't have to assume that. There are ways to mathematically
prove it. I can't articulate it. But there are people who can.
But I can't see a method to be safe if you don't assume your ISP is
after you, say. They'd easily make you to talk to an impostor CA
and you'd only detect if the public key of your CA was given to you
safely.
Let's say that you got the public key without it passing through your
ISP in an untrusted manner. This includes included on an OS
installation CD from a software vendor not passing through your
ISP. Likewise, passing through your ISP via an encrypted connection.
You have a priming issue, of how do you start the trust. Once you
have primed things and started the trust, it's relatively easy to roll
things forward.
(If you downloaded your browser or your OS by way of your ISP, then
your entire security rests on you trusting your ISP.)
Talk to the Debian Linux folks that insist on performing downloads
through HTTP without any encryption and relying on locally verified signatures.
Point being, you don't have to trust your ISP. There are ways to
validate what passes through them without trusting them.
My browser was downloaded from the Internet, so my ISP could've easily
given me an impostor browser with impostor public keys and CA
certificates.
Given many forms of security & protection that have been in common use
for 10–20 years, I think it's actually more difficult to get an illegitimate download than you seem to be describing.
My OS has been updated so many times (against my will), I have no
say what goes on in here.
You do have some say. The opportunity cost is high enough that most
people won't object.
True, but you'll have to bypass them at least on a first move.
If I don't trust my ISP, I can't see a way out of this.
I got lost here. The opportunity cost is high? What opportunity? Opportunity for what?
If I don't trust my ISP, I can't see a way out of this.
You need some seed of trust. That way you can authenticate what
passes through untrusted channels like your ISP.
I got lost here. The opportunity cost is high? What opportunity?
Opportunity for what?
You have the option of not accepting the updates. But doing so has
the opportunity cost of not benefiting from the foregone updates and
the hassle of doing so. Thus the opportunity cost, or what you pay /
give up by choosing to forego the updates.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 77:38:51 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,332,838 |
| Posted today: | 1 |