encryption

[Guest]

I have a client who wants to encrypt everything he sends out. Is there a way
to accomplish this?? I looked into digital certs and it looks like the
client also has to have a digital cert - however, my client wants all info
encrypted not just to one client. Is there anything out there to encrypt
outlook emails and attachments without this??? Thank you!

 

[VanguardLH]

I have a client who wants to encrypt everything he sends out. Is
there a way
to accomplish this?? I looked into digital certs and it looks like
the
client also has to have a digital cert - however, my client wants
all info
encrypted not just to one client. Is there anything out there to
encrypt
outlook emails and attachments without this??? Thank you!

E-mail certs have 2 keys: the private one that the recipient uses to
decrypt incoming mails and the public one the recipient gives to
senders. A user gets an e-mail cert but doesn't use it to encrypt his
e-mails. He gives it out to the senders, usually by first sending
them a digitally signed e-mail where the other person saves them in
their address book to also save the cert. When the sender wants to
encrypt an e-mail, they use the recipient's public cert. That way,
only the recipient has the private key to decrypt the mail. No one
else has the private key.

YOU:
- Get a cert (both private and public keys).
- Send a digitally signed e-mail to THEM so they get the public half
of the cert.

THEM:
- They save your cert (which only has your public key).
- When they want to encrypt a mail to YOU, they use your public key to
encrypt.

YOU:
- No one else has your private key. Anyone intercepting the encrypted
mail from THEM that used your public key will not have your private
key to decrypt the mail.
- You use your private key to decrypt mail that was encrypted using
your public key.

That means the only people that can send you encrypted e-mails are
those to whom you have given your public key (although it is possible
for them to share that mail or it gets intercepted and saved by
someone else). When your public key is used by them to encrypt a
mail, the only person that can decrypt that mail is you because only
you have the private key.

For YOU to send encrypted mail to THEM, they would first have give to
you their public key for their e-mail cert. Then you use their public
key to encrypt your message that you send to them. They use their
private key to decrypt your message.

If the content of the mail is not what needs to be encrypted but just
attachments, you could compress the file into a .zip file that
includes password encryption before attaching that .zip file to your
e-mail. However, how are you going to get the password to the
recipient so they can extract the contents of the .zip file? If you
include the password in your mail then obviously there was no point in
locking the file if you are going to give the key to the lock to
anyone that gets a copy of that mail. If you send the password in a
separate mail, anyone that intercepted your mail will also get the
password. You'll have to give the recipient the password through
another communications venue, like by telephone.

 

[Guest]

Thank you so much for the detailed response. It clears up a lot of my
misunderstanding of the encryption process. I will pass this on to my client
and see what he would like to do. I do know that he wanted to encrypt
attachments so I will discuss the zip and password process with him as well.
Have a great day and thanks again for the help!

 

[Brian Tillman]

I have a client who wants to encrypt everything he sends out. Is
there a way to accomplish this?? I looked into digital certs and it
looks like the client also has to have a digital cert - however, my
client wants all info encrypted not just to one client. Is there
anything out there to encrypt outlook emails and attachments without
this??? Thank you!

Public Key Infrastructure requires two cooperating parties: the sender and
the recipient. Both must have certificates. Why would anyone want to send
encrypted messages that the recipient can't decrypt? What would be the
point?

 

[Brian Tillman]

Thank you so much for the detailed response. It clears up a lot of my
misunderstanding of the encryption process. I will pass this on to
my client and see what he would like to do. I do know that he wanted
to encrypt attachments so I will discuss the zip and password process
with him as well. Have a great day and thanks again for the help!

Be aware, though, that the encryption contained in most zip applications is
relatively weak.

 

[VanguardLH]

in message

Public Key Infrastructure requires two cooperating parties: the
sender and the recipient. Both must have certificates. Why would
anyone want to send encrypted messages that the recipient can't
decrypt? What would be the point?

Actually only the one *receiving* an encrypted e-mail must have a
cert. Each cert has 2 parts: a private key the cert owner keeps
protected and a public key that gets doled out as an invite to have
someone else send the cert owner the encrypted e-mails. Usually he
gives it to whomever he wants (to receive encrypted e-mails) but it be
very public and millions could have his public key. You don't need to
protect the public key half of your cert. Anyone could use his public
key but they themself do not need their own e-mail cert. Only 1
e-mail cert is involved in the entire process and that's the one owned
by the recipient. Only the cert owner that sent out the public key
will possess the private key to decrypt the message.

Your e-mail cert is not involved, if you have one, when *sending*
someone an encrypted e-mail. You use the public key of the
*recipient* to encrypt your outbound message. The recipient uses
their private key to decrypt. The only one that needs a cert is the
recipient: they give you their public key to encrypt to them and they
use their private key to decrypt. This is a "pull" arrangement where
the recipient sends out invites (in the form of digitally signed
emails) to have others *send* him encrypted e-mails. Doesn't matter
if you have an e-mail cert. If the recipient didn't give you the
public key from THEIR cert then you cannot send them encrypted
e-mails.

The only person that needs an e-mail certificate is the one that wants
to RECEIVE encrypted e-mails. Encryption by using passwords on the
sender's end is a "push" arrangement and requires the password somehow
be delivered separately to the recipient. The OP's boss will need to
digitally sign his outbound e-mails so others can save his public key
(usually in their address book or contact folder). Then when
customers write to his boss, they will need to use his boss' public
key to encrypt their mails - providing they ever remember to do so.
That takes of encrypting inbound e-mails to his boss.

His boss having an e-mail cert does not take care of his boss
*sending* encrypted e-mails (because his boss would need the public
key from every customer to whom the boss wants to send e-mail). It
rarely works to get customers to all get e-mail certs (so they will
send you their public key). It's possible but x.509 has been around
since 1988, is probably supported by the vast majority of e-mail
clients (that support encryption), and has yet to catch on. Most
e-mail users look like deer caught in headlights when you ask if they
have an e-mail certificate so they can RECEIVE encrypted e-mails.
Besides using passwords for .zip files, other means are available to
encrypt e-mails by the sender but the problem is getting that password
to the recipient without obviating the security of the encryption used
in the first place. AES 256-bit encryption should be sufficient for
encrypted e-mails sent across the Internet. TrueCrypt is considered a
good encryption program and it defaults to using AES-256 (but you can
combine multiple encryption methods in TrueCrypt) but both sender and
recipient would need the TrueCrypt program installed -- and still
there is the problem of getting the password from the sender to the
recipient.

 

[Brian Tillman]

Actually only the one *receiving* an encrypted e-mail must have a
cert.

While technically true, it still requires two cooperating inviduals.

Each cert has 2 parts: a private key the cert owner keeps
protected and a public key that gets doled out as an invite to have
someone else send the cert owner the encrypted e-mails.

I don't need a lecture. I use PKI every day. I'm one of my company's PKI
administrators.