● The High-Tech How Not to be Seen, Part 4 - 荔园在线 | 深圳大学学生论坛,荔园晨风BBS,深大在线网站

荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀

发信人: "Roy Guo" <roy@szu.edu.cn>, 信区: Linux
标  题: The High-Tech How Not to be Seen, Part 4
发信站: ShenZhen University (Sun Dec  5 19:34:21 1999)
转信站: ShenZhen-University!bbs.szu.edu.cn!not-for-mail
出  处: 210.39.3.71

The High-Tech How Not to be Seen, Part 4

                               by Marcel Gagn~{(&~} <mggagne@salmar.com>
                                           29-Nov-1999

Who do you Trust? You've got to Trust SOMEONE!

Yes, it's time once again for SysAdmin's Corner. Before jumping into this
week's article (certificates, signing authorities, and
PGP/GnuPG-enabled Linux e-mail clients), let me take a moment to thank all
the German scholars out there who pointed out that
"Geheimnis" is German for "secrets".

When we left our current topic last week, some niggling little questions
remained. We could come up with a number of examples,
but essentially it comes down to this one simple question: "How can I trust
the source of a public key?" All right, two questions.
The other is, "If we're all sending signed and encrypted data, how can I
possibly verify every key on every web site or
keyserver?"

Suppose you work for Megacorp InterUniversal Inc., and corporate policy says
that all company e-mail must now be signed and
encrypted for it to be accepted by the system. Lately, your competitor,
UltraCorp MultiDimensional, has been trying to finagle
information from employees via bogus e-mails. No problem; your public keys
are posted on a keyserver so anyone can send you
encrypted e-mail. The problem is that MegaCorp has 23,000 employees and
business contacts. Again, how can you possibly
verify all those signatures?

In essence, that's the idea behind companies like VeriSign and GlobalSign.
They provide a certificate signing authority that
validates public keys. Whenever you visit a web site that runs a secure web
server (SSL), that server will present your browser
with a certificate generated by that site. Normally, you do not see this
exchange at all. That's because Netscape (and Internet
Explorer) employ various top-level signatures from trusted certificate
authorities to basically say, "Yes, that's a good signature.
You don't need to bother the user with this one." The question of trust has
already been answered for you.

If you want an example of what I am talking about, just visit your bank's
web site, then enter a secure page (check your bank
balance, or do something else that requires secure access). Other than that
little padlock icon on your Netscape browser changing
from the open lock to the glowing, closed lock, nothing really different
happens. Now, surf on over to my web server at
https://www.salmar.com/securepage.html and check out the difference. Your
browser will let you know it is receiving a
certificate from the Salmar web site. Since this certificate has not been
purchased (or signed) by someone Netscape has deemed
as trustworthy, you are now asked to verify that trust on your own. (Sure.
Sure. Of course, you can trust me.)

Now, click on that padlock icon on your Netscape browser. A window will pop
up with the title "Security Info". On the left-hand
side, click on "Signers" under the "Certificates" menu. A long list of
certificate authorities will appear. Any certificate sent to your
browser that has been signed by any of these CAs will simply be accepted.

The concept of a GnuPG or PGP web of trust is essentially the same.

Let's say I've just imported the key for user natika with the command
gpg --import natika.asc. Immediately, I decide to
encode a message to her like this:

     # gpg -ear natika message.txt

The system promptly responds with this message:

   Could not find a valid trust path to the key.  Let's see whether
   we can assign some missing owner trust values.

   No path leading to one of our keys found.

   1024g/486E4725 1999-10-19 "Marcel Gagne (Marcel's personal Key)
<mggagne@salmar.com>"
             Fingerprint: C337 4781 C7CD E8EE EBF0  0E2B 3968 E7EB 486E 4725

   It is NOT certain that the key belongs to its owner.
   If you *really* know what you are doing, you may answer
   the next question with yes

   Use this key anyway?

That's a good question. Natika is a user in the jungles of Antarctica, and
phone service is spotty. Getting in touch with her is
difficult at best. How can I verify that this key is valid?

Here's a quick refresher on the --edit-key option:

     # gpg --edit-key natika

If you type help at the command prompt, you will notice an option called
"trust" and another called "check". Last week, I had you
simply sign the key so that you wouldn't go through this question-and-answer
dialog. Let's type check and see what natika's key
says.

Command> check
uid Natika Feline <salmar@salmar.com>
sig!       9486A537 1999-10-20   [self-signature]
sig!       2E5230F8 1999-11-25   Australian Rainbow <rainbow@salmar.com>

The key has two signatures, one from the key owner herself and the other
from someone who goes by the handle "rainbow". This
is where trust comes into play. It turns out I know "rainbow" and his
signature. What does that mean to my level of trust regarding
Natika's key? When I first imported rainbow, I entered my --edit-key dialog
and chose "trust". I was given four options, from
1 (don't know) to 4 (I trust this person with my credit card). Depending on
the trust relationship I have assigned to the user
rainbow (in this case, complete and total), I can now accept Natika's key
and will sign it based on his recommendation. That's
because rainbow is my third party, the signing authority I can safely use to
verify another's signature.

As we sit back and watch the machinations of governments, security agencies,
and large conglomerates vying for their piece of
the pie in trusted PGP certificates, it's worthwhile to have a look at the
following URL and read their fourfold statement of
purpose; in particular, number 4.

http://www.cl.cam.ac.uk/Research/Security/Trust-Register/index.html .

Not everyone needs something like this, of course. If you just want to
exchange trusted or encrypted e-mail between a few
friends, then a worldwide signing authority is not a requirement. Even now,
though, companies are already selling validated PGP
certificates, and business is growing. All those interested in secure e-mail
and secure communications would do well to keep an
eye on associated developments.

This brings me to e-mail. One problem with all this secure communication is
the lack of Linux e-mail clients which work with PGP
or, even worse, GnuPG. Using my KDE mail client (which has rudimentary PGP
support, but not GnuPG), I can decode any PGP
or GnuPG message sent to me by saving it to a file, then using the following
command to decrypt it:

    # gpg -d message.txt

This works fine, but it is sloppy. One client you should consider looking at
is mutt, a curses-based e-mail package with more
configuration options than you can imagine. No, it's not pretty and
graphical, but it is powerful. The URL for mutt is
http://www.mutt.org .

A word of caution, though; mutt has some strangeness when it comes to
handling GnuPG. The site claims that GnuPG integration
is currently being worked on, but a little digging was still necessary to
make things work. For instance, the gpg-related stuff you
need is sitting in the /contrib directory in a file called gpg.rc (you
simply incorporate it into your own .muttrc file). The problem is
that it makes calls to gpg-2comp. I changed every reference of this to
"gpg", and things worked well. As with many open-source
projects, the development of both mutt and GnuPG is continually evolving.
Some of GnuPG's earlier commands have been
wrapped into a single "gpg" command.

If you decide to try out mutt, make sure you get the right version for
PGP/GnuPG support. You will need to download the
international version (the version number will be suffixed with an i). For
instance, I am using the latest version from the mutt ftp
site, mutt-1.1.1i.tar.gz. The URL to the ftp site is
ftp://ftp.mutt.org/pub/mutt/devel/ .

If you prefer to use PGP instead of GnuPG, you will find a few additional
e-mail clients such as Postilion and even a PGP plug-in
for Pine. This is one area, however, that still needs a little work.

Anyhow, that's it for now. Thanks again for visiting. Until next week, run
silent, run encrypted!

Copyright ? 1999 Specialized Systems Consultants, Inc.

荔园在线首页友情链接：深圳大学深大招生荔园晨风BBS S-Term软件网络书店