I need suggestions for programs to use to encrypting email from Outlook 2013
I need suggestion for software that I can use with Outlook 2013 to encrypt email. There is no exchange server involved
Not really sure what other information to post, so if you need more information let me know
Thanks
Not really sure what other information to post, so if you need more information let me know
Thanks
Dave Baldwin
You know that the receiving party has to have the same program so they can decrypt the email to read it?
ASKER
No, my understanding was if they had access to the public key they would be able to decrypt the message. Are you saying there is no standards for encrypting and decrypting email and everyone does their own thing?
s/mime encoding using a certificate and pretty good privacy (symantec) come to mind.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
one 3rd party mailbag service i reviewed last month is www.mycloudstar.com - it looks really slick and the average cost is around $5/user/month
this ensures encrypted transmission from you to outside parties but doesn't leave it encrypted in your sent folder or in their inbox, only during transport
on the plus side, no passwords, keys, exchanges, etc... which means you can send to literally any email address on the fly
plus you can set rules in their control panel - encrypt only if the subject/body contain keywords, sensative info patterns (ssn/cc) etc
this ensures encrypted transmission from you to outside parties but doesn't leave it encrypted in your sent folder or in their inbox, only during transport
on the plus side, no passwords, keys, exchanges, etc... which means you can send to literally any email address on the fly
plus you can set rules in their control panel - encrypt only if the subject/body contain keywords, sensative info patterns (ssn/cc) etc
There are several methods for encrypting emails. The same method must be used at both ends. There isn't just one standard method.
HIPPA/PCI compliance can not be satisfied on a computer or server that "non-authorized" people have access to. Both standards require physical security as well as encryption of transmissions.
HIPPA/PCI compliance can not be satisfied on a computer or server that "non-authorized" people have access to. Both standards require physical security as well as encryption of transmissions.
ASKER
I tried symantec but had a problem when sending an email that had a mix of recipients, 1 encrypted and 1 unencrypted. The problem was that if both recipients went through Gmail the encrypted email was thrown away because both messages had the same message id and Gmail thought the second was a duplicate, which always seem to be the encrypted email.
I'll have to ask about the email being in the inbox and sent box unencrypted, but it is interesting. Does the person receiving the link have to authenticate to see the email
We wanted the email to be encrypted when it sent and arrives and while it was in the client so we didn't have to worry about laptops.
I'll have to ask about the email being in the inbox and sent box unencrypted, but it is interesting. Does the person receiving the link have to authenticate to see the email
We wanted the email to be encrypted when it sent and arrives and while it was in the client so we didn't have to worry about laptops.
"I'll have to ask about the email being in the inbox and sent box unencrypted, but it is interesting. Does the person receiving the link have to authenticate to see the email"
you can choose this in the control panel of the 3rd party - default is no, because you would still need to get the password to them, and presumably if they have access to the inbox which would have received the email in the first place where they got the link... they would have seen the email anyway
this setup doesn't encrypt the emails in sent or inbox, only during transmission - though you should already be using a form of whole-disk encryption on the laptops anyway (truecrypt, bestcrypt, drivecrypt, etc)
you can choose this in the control panel of the 3rd party - default is no, because you would still need to get the password to them, and presumably if they have access to the inbox which would have received the email in the first place where they got the link... they would have seen the email anyway
this setup doesn't encrypt the emails in sent or inbox, only during transmission - though you should already be using a form of whole-disk encryption on the laptops anyway (truecrypt, bestcrypt, drivecrypt, etc)
OK, probably best if we take this from the top.
For almost all email security solutions (including S/Mime, which is *built into* outlook so you don't need to buy any other product) the recipient must first generate a keypair, send the public key to the sender, and keep the private key. For S/Mime, CAs would usually advise that you go with purchasing those from them, but in fact, the Microsoft CA can auto-generate certificates for exchange users (so if your correspondent has exchange, they can go this route) or you can generate your own with the free tool HERE
However, the key (no pun intended :) is to have the public key for your intended recipient before you begin; for this therefore, you should verify with those recipients what solutions they support, and obtain their public key (if they already have pgp, then you may need to purchase this to be compatible with their current usage, but usually they will be happy enough to go with self-generated S/Mime certificates)
Now, you *can* also go for the forms of mail encryption that don't require this; symantec (with their pgp universal), cisco (with ironport CRES), zixmail (with a range of products from single-host software to appliances) and Microsoft (with their hosted encryption solution recently renamed to Office365 encryption) all have offerings in this space - they aren't cheap, but they rely on the recipient setting up a login to decrypt their encrypted mail after receipt; for all but the symantec solution, that account will be with the vendor (who therefore has access to the mail stream should they choose to abuse that) - symantec's pgpu has an appliance on your own site that handles that for you locally.
But all that said... your next step is to go have a word with your recipients, suggest that if they don't have a solution already that they adopt S/Mime (because its free and they already have the software!) and get back to us if you have any problems with either that, getting your keys generated, or need advice on getting some other solution to work that your recipients have already adopted.
For almost all email security solutions (including S/Mime, which is *built into* outlook so you don't need to buy any other product) the recipient must first generate a keypair, send the public key to the sender, and keep the private key. For S/Mime, CAs would usually advise that you go with purchasing those from them, but in fact, the Microsoft CA can auto-generate certificates for exchange users (so if your correspondent has exchange, they can go this route) or you can generate your own with the free tool HERE
However, the key (no pun intended :) is to have the public key for your intended recipient before you begin; for this therefore, you should verify with those recipients what solutions they support, and obtain their public key (if they already have pgp, then you may need to purchase this to be compatible with their current usage, but usually they will be happy enough to go with self-generated S/Mime certificates)
Now, you *can* also go for the forms of mail encryption that don't require this; symantec (with their pgp universal), cisco (with ironport CRES), zixmail (with a range of products from single-host software to appliances) and Microsoft (with their hosted encryption solution recently renamed to Office365 encryption) all have offerings in this space - they aren't cheap, but they rely on the recipient setting up a login to decrypt their encrypted mail after receipt; for all but the symantec solution, that account will be with the vendor (who therefore has access to the mail stream should they choose to abuse that) - symantec's pgpu has an appliance on your own site that handles that for you locally.
But all that said... your next step is to go have a word with your recipients, suggest that if they don't have a solution already that they adopt S/Mime (because its free and they already have the software!) and get back to us if you have any problems with either that, getting your keys generated, or need advice on getting some other solution to work that your recipients have already adopted.
ASKER
Email has to be encrypted in the sent and inbox. If it is on a laptop and gets stolen it cannot be in plain text
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Really, as David suggests you should be looking at FDE for laptops - there will be other sensitive data on there as well as email. However, it is worth nothing that S/MIME encrypted messages are stored encrypted and decrypted only when displayed - you can set the client to prompt for a password before that happens also if you specify this when importing the pfx file containing certificate and secret key.
You can try this *for free* for yourself - download the xca tool and create two pfx (pkcs#12) files - one for your email account, one for a second (test) account. Import each into a separate laptop (literally, you can just double-click the things) and try sending encrypted mail back and forth from outlook.
Note, to send encrypted mail with outlook/smime you need the recipient's certificate first. easiest way to get the certificate to a remote user is to send a signed email, but in this case, you can simply export a pem copy of the certificate (again, from xca) and import that when importing the pfx.
You can try this *for free* for yourself - download the xca tool and create two pfx (pkcs#12) files - one for your email account, one for a second (test) account. Import each into a separate laptop (literally, you can just double-click the things) and try sending encrypted mail back and forth from outlook.
Note, to send encrypted mail with outlook/smime you need the recipient's certificate first. easiest way to get the certificate to a remote user is to send a signed email, but in this case, you can simply export a pem copy of the certificate (again, from xca) and import that when importing the pfx.
ASKER
FDE is under way separate from the email question, like you say there is other sensative data on the machines.
I am going to take Dave and Wylie's suggestion and work on the s/mime implementation. It will take me a few days to work through the testing and then I will be back
Thanks
I am going to take Dave and Wylie's suggestion and work on the s/mime implementation. It will take me a few days to work through the testing and then I will be back
Thanks
ASKER
Went with the 3rd party and FDE encryption due to the number of different people we have to deal with and not being able to control what the other party wanted to use to ebcrypt email
Thanks for the help and sorry I didn't get back to you earlier
Thanks for the help and sorry I didn't get back to you earlier