encrypting email?

[none]

I'd like to start encrypting emails (Outlook Express). Googled and found an
ID certificate is required and VeriSign will gladly produce one for $19.95 a
year.

Would like comments and input regarding encrypting, sources for certificates
etc; no experience with it although I recall hearing many years ago of a PGP
(?) method.

 

[VanguardLH]

I'd like to start encrypting emails (Outlook Express). Googled and found an
ID certificate is required and VeriSign will gladly produce one for $19.95 a
year.

Would like comments and input regarding encrypting, sources for certificates
etc; no experience with it although I recall hearing many years ago of a PGP
(?) method.

Thawte used to provide free e-mail certs. They even had some trust
network where you could upgrade your cert to higher levels (that had
more proof that the cert was yours) which were free or had some small
fee. Then Verisign acquired Thawte. For about a year, the Thawte
division of Verisign still provided free e-mail certs. Then at some
point I noticed that certs were expiring prematurely or couldn't be
renewed (I forget which since it's been too long ago since it happened).
Verisign stopped doling out free e-mail certs through Thawte.

I don't how many e-mail cert authorities still provide free certs but it
seems the last one (that I know of) is Comodo. As with all e-mail
certs, all they certify is the e-mail address you used to get the cert.
They don't verify you are you (i.e., your name or any other personally
identifying information). You are getting them free and the only
validation they do on that cert is send it to the e-mail address you
claimed was yours. This is similar to how confirmation works when
registering to access a site, like a forum: you give them your e-mail
address and they send the confirmation to that e-mail address. If you
gave someone else's e-mail address then you wouldn't get their
confirmation e-mail. So while there is some value in a free e-mail
cert, it is of very limited value. All it proves is that the e-mail
address in the cert you use when digitally signing e-mails (or when
others use your public key to encrypt their e-mails they send to you) is
your e-mail address. They don't provide any info about YOU.

http://www.comodo.com/home/email-security/free-email-certificate.php

Having an e-mail certificate installed for use by your e-mail client
does NOT let you encrypt e-mails that you send to others. It only lets
you digitally sign your outbound e-mails. Obviously you need to use the
correct cert with an e-mail address as the cert has to match from where
the e-mail got sent. To send encrypted e-mails means you need someone
ELSE's public key from their cert. They send you a digitally signed
e-mail. You save their cert (its public key) in your contact record for
that sender. Later you use THEIR public key to encrypt your e-mail that
you send to them. They can use their private key to decrypt your
e-mail. Only they have their private key, so you could copy multiple
recipients onto your encrypted e-mail that uses the one recipient's
public key and no one will be able to decrypt it except that one
recipient who has their matching private key. x.509 encryption is by
invitation: you digitally sign your e-mail when you want to invite
someone ELSE to use its public key to encrypt their e-mails that they
later send to you.

 

[Paul]

I'd like to start encrypting emails (Outlook Express). Googled and found
an ID certificate is required and VeriSign will gladly produce one for
$19.95 a year.

Would like comments and input regarding encrypting, sources for
certificates etc; no experience with it although I recall hearing many
years ago of a PGP (?) method.

Well, start with a background article, and see what you think.

http://en.wikipedia.org/wiki/Pretty_Good_Privacy

*******

http://en.wikipedia.org/wiki/Enigmail

http://en.wikipedia.org/wiki/Mozilla_Thunderbird#Security

http://www.enigmail.net/documentation/quickstart-ch2.php

"Publishing your key

By far, the easiest way to share your key with the world
is to publish it on the public keyserver network, a global
database of keys (please note that once a key was uploaded
to a keyserver, there is no way to delete it from there!).
In order to publish your key, click on your key in the Key
Manager. Then click "Keyserver" and select "Upload public keys".
"

Putting your public key on a public keyserver, is how other people
acquire the key necessary to send messages addressed only to you, where
the message can only be opened with your half of the key (the "private"
part you keep protected at home). This solves the problem of
"sending a secret" to your friend. The public key, by itself, is
useless. And you hold onto the private key, that finishes the job
on reception of an encrypted message. They use your public key, to
encrypt their mail to you.

From the first article:

"Web of trust

Simply downloading a public key from somewhere is not overwhelming
assurance of that association; deliberate (or accidental)
impersonation is possible."

So if the key on the server, was put there by the FBI, you could send
a message to person "X", and the FBI could use their private key to
read it. If they allowed the message to be forwarded to you, your
private key would not open it (because the bogus public key on the
server, isn't actually paired with your private key). But, I suppose
they could forward the plaintext they decoded, and apply your real
public key to it.

"PGP's original scheme, at least, leaves the decision whether or
not to use its endorsement/vetting system to the user, while most
other PKI schemes do not, requiring instead that every certificate
attested to by a central certificate authority be accepted as correct."

Would that be your $19.95 Verisign certificate ?

In any case, you should never have to send more than your public key
to a third party. Whether to have a certificate made or whatever. The
private key, stays with you. It should never be required, to submit
both the public and private parts, to a third party.

Looking at this info, it suggest making a key for yourself, isn't
a problem. But distributing it, in such a way as a third party can
trust the key belongs to you, is the hard part. They could encrypt
with what they think is your public key, only to have the content
decrypted by an "interested and capable" third party. If you could
give the key, by hand, to the recipient, then there would not be
a distribution problem. Not even snail mail would be safe, if
for example, all the snail mail was being intercepted. (For the
short period I worked at a postal sorting station as a student
summer job, two street addresses were on the intercept list. So
it does happen. There were the usual jokes about how "bad ass"
the person at that address might be. But none of my fellow
employees expressed an interest in informing the addressee they
were under surveillance. And the person most likely to snag
the items in question, would be the postal carrier about to
do his/her walk.)

If "nobody is really interested in you", and you're worried about
plaintext messages all being stored here, then a simple public
key, thrown on a keyserver, should be plenty. If "somebody is
interested in you", that's when more thought has to go into
key distribution (certificates, hand delivered etc).

http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/

HTH,
Paul

 

[VanguardLH]

To summarise what VanguardLH said at length: certificates are for
proving (to some extent) that you are you, not for encryption.

Encryption is something you do, usually using encryption software and a
public key which has been sent to you by the person you wish to sent the
encrypted email to. Some email software (probably including Outlook
Express) can interact with the encryption software to make the sending
of encrypted email more easy, making it appear to be part of the
emailing process.

(Of course you can scramble any file without anything from the
recipient, but you then need some way of telling the recipient how to
decode it, and telling them that risks being intercepted by
whoever/whatever is intercepting your mail anyway, which I presume is
why you're looking into it at all.)

To identify if the cert is valid requires looking it up at a CA
(certificate authority) to validate the status of that cert. The cert's
key must match that on record at the CA. Identifying you only by e-mail
is hardly identifying you. All it tells the recipient is that the
e-mail probably came from the e-mail address on record at the CA for the
owner of that cert. How do you verify the identify of someone sending
you a digitally signed e-mail (that only verifies the e-mail address)
who is sending from a free Hotmail account? Could be anyone that opened
that Hotmail account and then got a cert that has that same e-mail
address on record at the CA for that cert. So, yes, "certificates are
for proving (to some extent) that you are you" but your "not for
encryption" statement is incorrect. That same public key of yours is
usable by others to encrypt e-mails they send to you.

x.509 encryption relies on the 2-key scheme: a private key that only the
cert owner possesses which they use to decrypt e-mails that got
encrypted using their public key (which they doled out by digitally
signing an e-mail sent to someone else). x509 encryption *support*
(http://en.wikipedia.org/wiki/X509) is built into the e-mail client but
the actual encrypting is performed by calling the crypto API already
included within Windows.

E-mail certs serve two functions: to identify yourself to others and to
invite others to send you their encrypted e-mails. Once you send a
digitally signed e-mail, you really have no control over whether a
sender uses it or not to encrypt their e-mails they send you. Well,
normally that's the case. You can log into your account at the CA
(where you got the cert) and revoke your own certs so senders cannot use
them successfully anymore.

The cert repository is stored in Windows. Run "certmgr.msc" to see it
(look under the Personal category). It's worthless (for e-mails) unless
the e-mail app supports the cert store, has x.509 support, and it calls
the crypto API. Most the e-mails clients that I've used support x.509.
Some users perfer to use PGP but you'll need to use an e-mail client
with in-built support for PGP or to which you can install extensions or
plugins to add PGP support. See http://en.wikipedia.org/wiki/X509 which
mentions "This contrasts with web of trust models, like PGP" and then
read http://en.wikipedia.org/wiki/Web_of_trust. No thanks.

Certs can identify you (sometimes to a limited degree) AND permit others
to use its public key to encrypt e-mails they send you. It was designed
to permit encryption rather than relying on external measures, like
creating a .zip file with a password, which meant you needed an
alternative communication venue to the recipient to tell them how to
decrypt your encrypted message. Well, if you're sending e-mails there
is possibility that you don't have their phone number to call and tell
them the password, but if you have to call them then why bother with the
e-mail?

 

[BeeJ]

none formulated the question :

I'd like to start encrypting emails (Outlook Express). Googled and found an
ID certificate is required and VeriSign will gladly produce one for $19.95 a
year.

Would like comments and input regarding encrypting, sources for certificates
etc; no experience with it although I recall hearing many years ago of a PGP
(?) method.

You want auto encryption as you email?
You want what level of encryption?

One free way that you can do:
Download and install 7-Zip. 7-Zip is open source.
7-Zip file with encryption, and email.
This compresses and encrypts the file a double benefit.
Note that the .zip format name may be troublesome for some mail
providers but just rename the .zip or other standard type extension to
something else like just .z

Will that work for you?