Discussion summary on improving SSH

SSH (OpenSSH) is a workhorse for secure web administration and, as such, important for managing Internet servers including email. SSH is, usually, the only way to access remotely located servers. Of course, this makes SSH a valuable attack target.

There are established practices for securing SSH. However, they currently rely substantially on additional systems, that also present their problems and add to the maintenance burden.

After some discussion in the cryptography@metzdowd.com list and in private, I present below a summary of the dialogue and clarifications with a view to improve SSH. I've divided it in sections A-F, to make it easier to discuss.

A. THE SIX SSH ISSUES
The free test tool Nessus allows a remote SSH server to be quite easily discovered and explored by automated scans & attacks. The information obtained in SSH server scans can be typically divided (from the view point of a sys admin) in six issues (to be discussed later, this is just a list):

1. no way to block scanning and attacks
2. does not learn from attacks
3. advertises itself and the server OS
4. allows empty authentication requests (eg, requests by invalid users)
5. sends host key fingerprint to invalid users (eg, with no username)
6. sends a reply to invalid users (eg, with no username)

These issues, alone or in combination, can lead to multiple vulnerabilities, some with higher security significance than others (according to operational factors as well).

B. CRYPTO
Let's first state that not all the six issues are created by crypto use in SSH. And this leads us to the main question here:

Could new crypto in SSH help mitigate or solve any of these six issues?

Currently, how are these issues addressed? By non-portable and potentially buggy methods (see below), with more software that has to be patched, updated, configured and tested, all at different times, with added security gaps that can be compromised.

New crypto methods in SSH could do a better job by reducing the problems in the first line of defense at SSH itself and by avoiding security gaps. Non-crypto things such as PAM, tcpwrapper, port-knocking, grey-listing and others can always be added later anyway, if desired.

C. PASSWORDS
Some issues could be minimized by turning off password authentication, to use only private/public keys (PKs). SSH allows users to generate PKs without cost (no need for a CA). Users can keep their private keys in their drives and also in a USB dongle, for example. One can also add second-channel authentication (e.g., RSA SecurID) to SSH with a PAM or a patch.

However, turning off password authentication is not desired in many cases, even when PKs and second-channel authentication are used.

Password authentication may be more secure against attacks on the client, to gather information before compromising the server. According to Peter Gutmann, a study of SSH attacks a few years ago showed that nearly two thirds of all SSH private keys were stored on disk with no password protection at all, so that simply being able to read a hard drive will get you access to any number of systems without having to trojan the SSH client or plant a keyboard logger as you'd need for an SSH password. So turning off password authentication could make things less secure, not more.

Another reason for using passwords in SSH, and perhaps more compelling, is that you don't want to risk getting locked out just because your disk died, you forgot your laptop, SecurID or USB dongle, and the private key cannot be found (for security reasons!) in the back-up. Passwords can also easily be given over the phone from sys admin to sys admin, and are easily protected by threshold cryptography. And using a private/public key pair in SSH would anyway require a password for protecting the private key.

Using good, high-entropy passwords turns out to be preferred by many sys admins because it is simpler, more portable, and works fine for security (provided the password is chosen with enough entropy). Sys admins already need to use many passwords for many servers and protocols, and have safe methods for off-line storage, redundant record keeping, and authorized record access (including a handwritten notebook, encrypted USB dongles, and a printed list), that are of course not kept near the computer.

D. PAM
Some of the issues can be solved with SSH PAM, such as pam-abl. However, PAM libraries are usually buggy (buggier than SSH), and might be unstable unless suitable PAM items were added by which the daemon can communicate the client IP address and port number, and maybe other things too.

E. SOLUTIONS
I believe that each one of the issues 1-6 can be met by a cryptographic protocol deployed in SSH. Some solutions are well-known. BTW, there were some similar issues in the SSL protocol.

F. ISSUE BY ISSUE REVIEW

#1. no way to block scanning and attacks

Firewall port-knocking can help here. It is hard to guess and defeat; nothing shows up in scanning. However, it is not portable and is hard to debug and use.

While there are also IDS that can turn off the SSH port if a scanning is detected, this can lead to DoS.

Pam-abl can also help, but PAM is usually buggier and adds security gaps.

Possible solution: SSH could easily incorporate some of the pam-abl code, enough to block an IP for some time T after N failed attempts, self-clearing after T.

#2. does not learn from attacks

Possible solution: SSH can incorporate some of the pam-abl code for this purpose.

#3. advertises itself and the server OS

"Need to know" is a valuable security policy.

Advertising the OS may compromise a higher security function (the OS) in the case of a zero-day or unpatched exploit. SSH MUST NOT advertise the OS. It may compromise policies and apps in a lower (more critical) layer than SSH, not just the OS.

Also, advertising SSH's innards in "already dead" authentication has no useful purpose that could not be more securely met.

Possible solution: let the client tell its version to the server, for the server to decide if it is acceptable -- it is a server function anyway (eg, not to accept SSH v1).

Additionally, it would also be useful for the client to send to the server a list of acceptable configurations, for the server to select, so that the server would no longer be groping in the dark as to what algorithm and parameters to use.

#4. allows empty authentication requests (eg, requests by invalid users)
#5. sends host key fingerprint to invalid users (eg, with no username)
#6. sends a reply to invalid users (eg, with no username)

- Some claim that the SSH protocol requires key exchange to occur before the user identity is sent, as it protects the user identity from disclosure to an impersonator.

However, if the user does not have a valid username, why and what should the server have to prove to that user? Invalid data deserves either "no response" (safer) or an error response. The SSH server should not do work or provide information to an user that is known already to be invalid. The SSH protocol needs improvement here.

- Some also claim that if the SSH protocol would permit such differing responses for valid/invalid users, then attackers can use SSH as an oracle to determine username validity.

However, SSH can prevent username enumeration by trial and error. With a simple keyed-hash, if this protection is desired, one would just enter the same key for the server and clients, so they can be all using the same transform. This is a simple mechanism that hackers cannot break by guessing. Note that SSH already uses a hash mechanism to hide domain names in the hosts file.

- Some claim that the issues #4 and #5 are actually "features" that are used by some of the anonymous services, such as anonymous CVS.

However, these "features" could be closed by default, and opened in the sshd config file if desired. This may also need some cryptographic protocol changes.

Because the reported issues could be improved by adding crypto, I am asking for more input first, before taking these issues to the OpenSSH development list. This should help the development effort. The OpenSSH development mailing list is at:
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Thanks for all the input! Comments are welcome.

Cheers,
Ed Gerck

Re: NPR : E-Mail Encryption Rare in Everyday Use

...

I personally would prefer to sign every email I send. I'd also
prefer to encrypt all non-public messages. I am fully competent
in the use of the current technology, but it turns out to be not
practical to use.

Greg

Re: NPR : E-Mail Encryption Rare in Everyday Use

Paul Hoffman wrote:

This is my original disagreement with Ed's message. It can be done, and when you do it it works, but it is too difficult for most people to bother with. I think we all agree on those three facts, just not on what to label the last one.

Actually, when I wrote "it does not actually work" I meant all three things:

1. It can't be done as a user would like to do it; note also that even experts
do it incorrectly (it's just too many detail devils).

2. When a user does it, the user does not really know if it was done right.

3. It is too difficult for users to use and (worse) most users who use it
do it incorrectly.

We have some choices. We can continue to say that it works and just wait
for users to get educated someday. Or, we can say that there is no x (x = market,
need, risk, point) -- and that's why no user bothers with it. Or, we can try
to understand what's it that users reject and work around it. My opinion I
already say upfront: users reject the whole model; it's not "natural" to
ask me for my envelope before you can send me a letter.

(btw, name and mail address are not the envelope -- they are routing
information. My public-key is the envelope analogue when comparing postal mail
with secure email.)

Cheers,
Ed Gerck

Re: NPR : E-Mail Encryption Rare in Everyday Use

Phil Z doesn´t know how to do it himself, at least with PGP.
He told me that he doesn´t sign people´s keys who ask for it,
simply because it would pollute his keyring on his computer,
and he couldn´t work with a keyring with thousands of people
on it anymore.

So PGP obviously has a usability and scalability problem.
So he only signs the keys of his friends because of that.
I wonder now, why he didn´t tried to solve that
usability/scalability problem himself yet, but gave up instead.

Best regards,
Philipp Gühring

Re: NPR : E-Mail Encryption Rare in Everyday Use

Paul,

Usability should by now be recognized as the key issue for security -
namely, if users can't use it, it doesn't actually work.

And what I heard in the story is that even savvy users such as Phil Z
(who'd have no problem with key management) don't use it often.

BTW, just to show that usability is king, could you please send me an
encrypted email -- I even let you choose any secure method that you want.

Cheers,
Ed Gerck

Re: NPR : E-Mail Encryption Rare in Everyday Use

Ed Gerck wrote:

This story (in addition to the daily headlines) seems to make the case that
the available techniques for secure email (hushmail, outlook/pki and pgp) do
NOT actually work.

That's an incorrect assessment of the short piece. The story says that it does actually work but no one uses it. They briefly say why: key management. Not being easy enough to use is quite different than "NOT actually working".

--Paul Hoffman, Director
--VPN Consortium

NPR : E-Mail Encryption Rare in Everyday Use

This story (in addition to the daily headlines) seems to make the case that
the available techniques for secure email (hushmail, outlook/pki and pgp) do
NOT actually work.

http://www.npr.org/templates/story/story.php?storyId=5227744

Cheers,
Ed Gerck

Re: Comparison Of Secure Email Technologies X.509 / PKI, PGP, and IBE

Andrew,

You make some good points. The purpose of the paper is to show
where and what the problems are -- and motivate solutions.

The points you note are not technology limitations of usability
but implementation problems. Also, in business use, clients can
be chosen among those that work and the proper infrastructure
provided. The usage difficulty ("I can't even use it") exists
mostly for open-ended Internet use. Of course, we still have all the
other difficulties pointed out in the paper

Regards,
Ed Gerck

--- Andrew Patrick wrote:
> Hi;
>
> I have not read your paper in detail, but thought I
> would mentioned problems that I have had in using
> X.509 based email signatures.
>
> It boils down to the fact that email messages signed
> with X.509 certificates break a number of message
> clients at the receiving end to the point that I have
> given up on signing my email.
>
> Some clients simply fail to display the signed
> messages (usually webmail systems).
>
> Other clients assume that a message received with a
> signature must be replied to in a signed fashion, and then
> break when the replier does not have a certificate
> configured (MS Outlook Express).
>
> Some mail clients alter the incoming message (i.e., to insert
> ads, ala Yahoo mail), so a message integrity check fails, and
> some usually cryptic error mesage is shown to the receiver.
>
> So, in my mind secure email systems suffer from the
> most sever usability problem -- they don't work.

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

James A. Donald wrote:

From: Werner Koch

You need to clarify the trust model. The OpenPGP
standard does not define any trust model at all. The
standard merely defines fatures useful to implement a
trust model.

"Clarifying the trust model" sounds suspiciously like
designers telling customers to conform to designer
procedures. This has not had much success in the past.

People using PGP in practice verify keys out of band,
not through web of trust.

James (and Travis, re previous posting on PGP trust model),

Yes. Your observation on out-of-band PGP key verification
is very important and actually exemplifies what Werner
wrote. Exactly because there's no trust model defined
a priori, uses can choose the model they want including
one-on-one trust.

This is important because it eliminates the need for a
common root of trust -- with a significant usability
improvement.

If the web of trust is used, the sender and recipient must
a priori trust each other's key signers, requiring a
common root of trust -- that may not even exist to begin
with.

So, instead of worrying about what trust model PGP uses,
the answer is that you can use any trust model you want --
including a hierarchical trust model as used with X.509.

Jon Callas and I had several conversations on trust in
May '97, when Jon visited me for two weeks while I was
in Brazil at the time, I think before the OpenPGP WG was
even working on these issues. This is one of the comments
Jon wrote in a listserv then, with a great insight that
might be useful today:

As I understand it, then, I've been thinking about some
of the wrong issues. For example, I have been wondering
about how exactly the trust model works, and what trust
model can possibly do all the things Dr Gerck is claiming.
I think my confusion comes from my asking the wrong
question. The real answer seems to be, 'what trust model
would you like?' There is a built in notion (the
'archetypical model' in the abstract class) of the meta-
rules that a trust model has to follow, but I might buy a
trust model from someone and add that, design my own, or
even augment one I bought. Thus, I can ask for a
fingerprint and check it against the FBI, Scotland Yard,
and Surite databases, check their PGP key to make sure
that it was signed my Mother Theresa, ask for a letter of
recommendation from either the Pope or the Dalai Lama
(except during Ramadan, when only approval by the Taliban
will do), and then reject them out of hand if I haven't had
my second cup of coffee.

Cheers,
Ed Gerck

Re: about secure email technologies

--- Dino Esposito wrote:

> Mr. Gerck
> I skimmed through your "comparison of secure email
> techs..." and it
> seems to me that some of the desirable features and
> problems are outside
> the scope of the proposed technics (PKI, PGP, IBE).
> I mean, they are
> requirements about the mail protocols (e.g. return
> receipt) or SSL
> (Server spoofing).

The secure email technology may be able to directly
include a feature, in which case there's a check mark.
If the feature can't be included, an additional protocol
may be used to provide it. For example, server spoofing
could be prevented in IBE, directly, when the user
connects to the PKG to get the key (prventing credential
compromise for the real PKG).

> My field is PKI, and I think PKI
> (perhaps PGP too)
> can supply some basic technologies in order to build
> a "Secure email
> system", but it's unable to supply the full
> solution.

which must, most importantly, be usable. That's why
the paper can be useful to both improve PKI (what's
missing?) and to provide a view to new technologies
that can overcome current limitations.

> In Italy we have set up a quite complex legal and
> technical framework in
> order to have a "registered email" with all the
> features of the
> traditional registered mail and some plus (not only
> the sending is
> certified, but also the content and the integrity of
> the messages). This
> framework rules the single message AND the mail
> service providers, that
> have to be accreditated as the most trusted
> Certification Service Provider.
> These rules do not address confidentiality (SSL is
> mandatory, but the
> accreditated mail servers are nevertheless able to
> read any message),
> but this is probably the simplest issue since
> encrypting the body of a
> message is quite easy

But decryption is not, as the private-key must
be protected. That's where it's more difficult.

> I'm going to summarize these rules in English for
> other purposes; if you
> are interested I can send you as soon as available.

Yes, please do!

> Finally, I think that "F17 Verified Timestamp" is a
> feature supplied by
> PKI: the timestamp token as defined by the RFC3161

Yes, it is. It's now added in the table.

Ciao,
Ed Gerck

Re: Comparison of X.509 / PKI, PGP, and IBE

- Michael Ströder wrote:

> Ed,
>
> you've asked for feedback on
> http://email-security.net/papers/pki-pgp-ibe.htm.
>
> "1. DESIRABLE FEATURES REFERENCE SHEET"
> I don't understand F18 and F19. Maybe you're
> referencing transparent
> encrypting of e-mail attachments? But then this
> should not be limited to
> HTML attachments.

Yes, you're right. It has been improved in the new
version at
http://email-security.net/papers/pki-pgp-ibe.htm

> Personally I'd never use a e-mail software which
> follows this requirement:
> "(**) [..] If the recipient wishes to decline to
> provide the receipt,
> the recipient should not attempt to decrypt the
> message."

This is the same rule that postal mail follows. The
receipt is useful for both sender and recipient, in
addition as evidence for the sender; for example, if
the sender knows that the recipient read (decrypted)
the email, the sender does not have to send another
email or make a call.

> "2. PROBLEMS / ATTACKS REFERENCE SHEET"
> P1 to P5 seems to be very much related to
> client-server processing. Are
> you pointing to web-based e-mail clients here? If
> yes, I'd suggest to
> make this more clear in the text by explicitly
> mentioning this type of
> service.

They apply to desktop-, intranet- or web- based. For
example P15 applies to PGP, web based or not.

> It's not clear to me why you list "F6 Base 64
> Encoding" as a feature.

It looks like a lame feature but some email products
do it better than others. For product evaluation you
can change the check mark to a product-specific grade.

Cheers,
Ed Gerck

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

Not to side track the discussion, but frequently I've heard PKI
compared to PGP's model.  Isn't PGP's trust model the same as everyone
being their own CA?

I find PGP to be problematic.  Many keys I see are only self-signed,
and this includes important keys like CERT.  Many others sit unsigned
on the same website you access to download the source code protected
by it.  And 90% of the time when they have more than one signature you
don't have a key that signed the other party's key, so you get to do a
breadth-first search manual-like (pathserver being dead and all).
Even with kgpg pulling the keys from a keyserver for you, it's still
non-trivial.

I successfully inspired a local keysigning, but it seems like most of
the people didn't see any immediate benefit, and so declined to
participate.  "What does this mean for me" was a common question.  I
tried to explain the purpose, but I suspect it is too recondite or too
far removed from their experience.  Perhaps I'd have better luck by
stating what kind of attacks it would prevent (email spoofing being
relatively rare, save for some obvious spam tactics).  I'm open to any
suggestions along these lines.

--
Travis H.

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

James A. Donald wrote:

> This was the scenario envisaged when PKI was created,
> but I don't see it happening, and in fact attempting to
> do so using existing user interfaces is painful.  They
> don't seem designed to do this.
> 
> My product, Crypto Kong, http://echeque.com/Kong was
> designed to directly support this scenario in a more
> convenient fashion - it keeps a database of past
> communications and their associated keys, but there did
> not seem to be a lot of interest.   I could have made it
> more useful, given it more capabilities, but I felt I
> was missing the point

i've seen some discussions that were either/or regarding pki & pgp;
aka pki advocates attempting to position pki as a OR to pgp. the issue
is that both pki and pgp require a local trusted public key repository
as the basis for establishing trust.

pki then layers on it, these certification authority business processes,
specialized digitally signed messages called digital certificates, etc
to address first time communication between strangers where the relying
parties have no other resources for determining information about the
sender in an offline environment. they then advocate that all
(personally) digitally signed operations are required to have attached
x.509 identity digital certificates that has been digitally signed by a
certification authority.

we saw some of that when we did work on the cal. state & fed. electronic
signature legislation
http://www.garlic.com/~lynn/subpubkey.html#signature

one possible interpretation might be that it would have increased the
revenue stream for the certification authority industry.

drastically improving the useability of the interface to the trusted
public key repositories could be viewed as having two downsides 1)
certification authorities that haven't payed to have their public keys
preloaded can more easily join the club, 2) the pgp-like scenario
becames much easier, potentially drastically reducing existing reliance
on the digital-certificate-only (and certification authority only
business process) digital-signed-operation model.

part of the problem with the trusted third party certification authority
model is that its primary benefit in the case of first time
communication betweeen two strangers ... where the relying party has no
other recourse to information about the other party. this is actually an
extremely small percentage of communications. we saw some of this
working on the original e-commerce activity
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

where we layed out hypothetical certification issues for merchants ...
including things like having FBI background checks for all merchant
employees. the problem is that e-commerce transactions have been quite
bi-model whith the largest percentage of transaction occuring as repeat
business with well-known merchants. in these cases, consumers have
established trust via a large number of other mechanisms ... so there is
little added value that a certification authority can provide ...
especially if they aren't willing to stand-behind and guarantee all
merchant transactions (ssl then is primarily countermeasure to
mitm-attack and evesdropping on transaction as opposed to a
certification/trust issue).

the rest of the remaining transaction are spread around to a large
number of different merchants having a few transactions each. the issue
here is that the incremental revenue flow for a few transactions a month
couldn't possibly cover the cost of a certification process that
involved things like fbi background checks on all merchant employees.

the large majority of transactions are either repeat business and/or
with extremely well-known merchants ... this doesn't satisfy the PKI
target profile of first time communication between complete strangers.
simple countermeasure to mitm-attack and countermeasure is achieved by
having stored the merchant's public key (from the consumer's standpoint).

from the merchant standpoint they already have transaction guarantees on
credit card processing from their contract with financial institution.
the threat/vulnerability model here is client-originated fraudulent
transactions that aren't strongly authenticated. here, x9.59 standard
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

allows for digitally signed transaction where the public key is
registered with the consumer's financial institution and the digital
signature is verified by the consumer's financial institution as part of
verifying the transaction.

the other part of x9.59 standard is that it specifies that account
numbers used in x9.59 transactions can't be used in non-authenticated
transactions. this eliminates both data breaches and evesdropping as a
threat/vulnerability for fraudulent financial transactions ... aka the
requirement given the x9a10 working group for x9.59 standard was to
preserve the integrity of the financial infrastructure for all retail
payments. if data breaches and evedsdropping no longer can result in
fraudulent transactions, then there is much less reason for
sophisticated countermeasures for those threat/vulnerabilities (ssl is
no longer needed to prevent evesdropping on the account number, since
evesdropping on the account number no longer provides any practical
fraudulent benefit).

simple public key registration as part of financial account operation
(in an onging relationship that a consumer has with their financial
institution) not only is a certificateless digital signature model
http://www.garlic.com/~lynn/subpubkey.html#certless

but also eliminates much of the requirement for existing major use of
digital certificates; that of providing ssl encrypted communication
http://www.garlic.com/~lynn/subpubkey.html#sslcert

as countermeasure for evesdropping for the purpose of account number
havesting
http://www.garlic.com/~lynn/subpubkey.html#harvest

furthermore, not only does simple x9.59 digital signature authenticated
transactions eliminate the threat/vulnerability of evesdropping for
account number harvesting, but it also eliminates the
threat/vulnerability of data breaches for account number harvesting
aka the harvesting could still go on, but the threat/vulnerability of
fraudulent transactions as a consequence of harvesting is eliminated ...
note that phishing attacks for the purpose of account number harvesting
is also eliminated as a threat/vulnerability ... phishing can still go
on, account numbers cna still be harvested, the account numbers are
useable for fraudulent transactions w/o the digital signature.

misc. past posts mentioned bi-model transaction distribution and/or
having suggested employee fbi background checks as part of merchant
certification process.
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption
Empower These Terrorists?
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean
Anything?

Anne & Lynn Wheeler

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

James A. Donald wrote:

> > However, the main point of attack is phishing, when
> > an outsider attempts to interpose himself, the man
> > in the middle, into an existing relationship between
> > two people that know and trust each other.

Anne & Lynn Wheeler wrote: 

> in the traditional, ongoing relationship scenario,
> relying parties directly record authentication
> information of the parties they are dealing with. if a
> relying party were to directly record the public key
> of the people they are communicating with ... it is
> the trusting of that public key and the validating of
> associated public key operations that provide for the
> countermeasure for man-in-the-middle attacks and
> phishing attacks.

This was the scenario envisaged when PKI was created,
but I don't see it happening, and in fact attempting to
do so using existing user interfaces is painful.  They
don't seem designed to do this.

My product, Crypto Kong, http://echeque.com/Kong was
designed to directly support this scenario in a more
convenient fashion - it keeps a database of past
communications and their associated keys, but there did
not seem to be a lot of interest.   I could have made it
more useful, given it more capabilities, but I felt I
was missing the point

        James A. Donald

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

On Fri, 9 Dec 2005, Ed Gerck wrote:

> [...]                                          at least the grand
> picture should exist beforehand. This is what this thread's subject
> paper is about, the grand picture for secure email and why aren't
> we there yet (Phil's PGP is almost 15 years old) -- what's missing.
>  

and Bill Stewart wrote:

> Popularity of a product is critical to its security;
> you don't gain anonymity if the Feds can recognize that
> you're one of the dozen users of a given application.
> Your mom can use Skype, but nobody she knows uses Crypto Kong,
> and I only know a few people who use PGP to email their mom.
> But some of the Instant Messaging systems use crypto;
> too bad that they're continually trying to be incompatible
> with each other to gain market share.

I think what's missing is the understanding that there cannot be
secure email without the persons involved acting responsible and
knowing their role in the process.

Your mother will probably expect the computer to do the job for her
(mine will never expect anything from computers) rejecting any
responsibility for her email's security. In my opinion establishing
secure email this way is impossible despite the fact that encryption is
(relatively) easy if our algorithms work as expected and you have the
correct high-quality public key.

And even if Instant Messaging systems would use the same crypto people
will use them like cell phones without any consciousness of their own
responsibility for key validation. Getting good crypto into mass products
can help but does not eliminate the necessity for checking essential
properties of the system they use.

How we can make this job as reliable as possible is the question at the
heart of the problem.

Ralf Senderek