Re: Why everyone uses envelopes but few encrypt emails?

Joseph Ashwood wrote:
"privacy concerned" <privacyconcerned@xxxxxxxxx> wrote in message
Joseph Ashwood wrote:
Actually, it can't, you MUST send the critical message AFTER key
EaSecure always sends it before, therefore you cannot address this

You can send the first EaSecure message without critical information -
just to make Bob to sign up. After making sure the real Bob has signed
up, you can send critical messages.

We're talking about security critical information, not whatever he's doing
with his mistress. The first message _is_ the critical message.

[polling DNS won't work]
I agree it is more complicated than I said and the fact DNS entries are
frequently changed also poses a problem. So Bob does need to be
diligent enough to notice the difference between bob@xxxxxxxxxxx and

Back to the "You must be this smart to be worth protecting"

Does PGP also requires the same type of diligence?

No it doesn't. PGP will gladly accept multiple keys for an email address,
then you independently verify them, or worst case trust the web-of-trust. An
impersonating key will not be verified by Bob because the fingerprint won't
match, and if you decide to use only the web-of-trust the fake Bob key will
only be signed by the MITM. The MITM fails.

Another improvement that can be made to EaSecure is to allow the user
to independently verify the "finger print" of the public key. For
example, one can use the EaSecure Key Manager to get a "finger print"
(e.g. the SHA256 hash) of the public key associated with an email
address. This will allow independent verification. However one still
needs to be diligent enough to do the verification, but I guess this is
probably the same degree of diligence required to use PGP properly.

Of course, exchanging keys in person will solve the problem. So I think
the improvement EaSecure can make is to allow exchanging keys in

That would be a huge improvement. A challenge system for email addresses
would also be helpful. What I mean by this is Bob can report that his public
key is wrong, and based on Alice's word as well, a public key can be
suspended. I'm not sure how to resolve the issue beyond that because you
don't have the facilities.

For example, EaSecure Key Manager may allow the user to export
public keys to be exchanged in person. The other user can import that
public key. After that, the EaSecure software will check if the public
key retrieved from the key server is consistent with the imported key.
If not, it will give warnings.

Just use the local imported key. As long as you're key server is signing the
key you should only have to verify it once a month.

Other systems that do not require this do not work like an envelope -
they cannot "send-to-anyone" (send the message before the recipient has
a public key).

And in exchange they can be secure against MITM.

I agree. There is a price for "send-to-anyone" functionality. However,
compared with other systems that have tried to implement
"send-to-anyone", the price paid by EaSecure seems to be the smallest.

No, every system where the security critical message is sent before key
generation fails in exactly the same way. There have been some very good
designs in the field, in particular ones that deliver a one-time-password to
the sender and require phone verification until the recipient has registered
are actually secure to the phone (the critical message is the phone call,
which is authenticated by human ability. as such it escapes the MITM

I agree, the security can be improved if "out-of-band" communication
can be used. Is there any better idea for "send-to-anyone" without
using out-of-band communication?