Is using Gmail and encrypted documents enough for secure email communication?

Question

My friend was asking me what would be the best way to exchange documents with clients.

He was trying to tell me that just sending the documents via email was sufficient and I told him he was insane. I think the only solution is PGP. It seems like there should be some slick way to do this. Any thoughts?

So I have two questions:

1. Am I right about Gmail being a bad idea? He claimed that he read this was a good idea in some professional journal.

2. Is there a service that could implement a secure point-to-point mechanism?

3. Would PDF or Office encryption be sufficient?

Answer 1

It sort of depends on what you are protecting.

Have a read of this question on what steps Google, Yahoo! and others take to protect webmail.

Also have a look at this question, giving alternate solutions on sending data. I tend to use pgp/gpg to encrypt before emailing, where possible or use a hosted secure mail (similar to the one @Paul described) for some clients.

You can secure the connection fairly well, but unless you encrypt your data before sending it, it will reside on Google's servers in the clear. This may be okay, but it may not - it all comes back to how sensitive the data in those messages are.

Answer 2

If both your friend and his clients use gmail, then security is not that bad... all data transfers between a user's machine and gmail are over HTTPS, and if both sender and receiver use gmail, the email never leaves Google's machines. So, as long as you trust Google, that's fine.

"Trust" is a nasty word. In the paragraph above, it means that Google does not voluntarily discloses the email contents, and also that they do a good job of protecting their servers (you trust them to be honest, and you trust them to be competent). But, ultimately, someone you trust is someone who has the power to betray you.

Also, Google is known to scan gmail users' emails, so that it can work out targeted ads to display to the users. This implies, at least in a theoretical way, that data from your emails necessarily flows out of Gmail servers, towards advertisers. A comforting thought.

To get better than gmail, you need end-to-end encryption. The classic products are S/MIME and PGP; the former is supported by mainstream email applications directly, but involves X.509 certificates, which can be a hassle to setup. PGP usually requires add-ons, but tends to be simpler to use. Note that most webmails are incompatible with either S/MIME or PGP: Outlook Web App can do S/MIME with a specific ActiveX control on the client system -- Windows/IE only, of course -- but most other webmail systems cannot. To some extent, PGP emails can be handled externally by transferring them with copy&paste (the normal format for PGP emails is "ASCII-armor" which is meant to be transferrable as plain text).

For one-shot communications, consider Zip archives with a password (password is exchanged over the phone). Older Zip implementations used a weak custom stream cipher (actually a good example of why homemade designs should be avoided). Newer Zip archivers (WinZip 9.0 and later, at least) use AES, which is much stronger. It all boils down to what the client is ready to install when asked by your friend.

Answer 3

You should take a look at the Mailvelope project. It is a Google Chrome extension that implements some of OpenPGP for Webmail. The UI is simple and clean.

Answer 4

In order to avoid clients needing to configure and manage encryption systems on their devices in order to communicate with the accountant, a secure file store like Accellion may be an option.

This works like webmail. You compose your email in the Accellion portal and attach your file and send to the customer. The file itself is not sent, but replaced by a link. The customer receives the email, and clicks the link to download via https the file.

Equally, they can use the accountant's service to send files to the accountant (but not to anyone else).

Answer 5

Although I dont agree with Luxsci (an email encryption provider) TLS is all thats required for the level of encryption for HIPAA compliance. I don't know what laws an accountant has to regulate their industry but Luxsci does have a FREE TLS checker at: https://luxsci.com/extranet/tlschecker.html

I would base my decision off of the industry specific requirements. If encryption is required then you may want to consider a commercial product that is easy to use like smarsh, webroot, zixmail, etc. I can say however to avoid trend micro has a horrible product from personal experience and since I switched vendors no longer have that issue.

Additional note: there are 2 main methods for commercial encryption, push and pull.

Push sends an email that contains an attachment that is actually encrypted and you decrypt the message locally. SOME businesses and definately hospitals BLOCK this since they can't read the contents. I would advise to stay away from this if possible.

Pull sends an email that you click on a link that takes you to a webportal to retrieve your message and attachments. This technique shouldn't trigger any firewall rules or get blocked because of how it's delivered.

Answer 6

I have been in a similar situation. The only option that I found universally acceptable for end users of all skill levels was to send files in an encrypted .zip file as attachments. On Linux these files are easy to create with the -e flag for zip:

$ touch foo.txt

$ zip -e foo.zip foo.txt 
Enter password: 
Verify password: 
  adding: foo.txt (stored 0%)

$ ls | grep foo
foo.txt
foo.zip

$ file foo.zip 
foo.zip: Zip archive data, at least v1.0 to extract

$ unzip foo.zip 
Archive:  foo.zip
[foo.zip] foo.txt password: 
password incorrect--reenter: 
replace foo.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: y
 extracting: foo.txt

Users on Windows or using a graphical interface on Linux (KDE, Unity, Gnome) can create encrypted .zip files by right-clicking on a file and selecting the "Encrypt" option from zip, and can decrypt by simply double-clicking.

Answer 7

Well gmail uses https everywhere so sending/receiving should be secure. I believe they have a good privacy policy so are you saying you need additional security in the case a google employee becomes a spy or someone cracks the password to someones email account? The former i dont believe you will want but the latter could be solved with 2 step verification.

Do you really need more? If you do and believe an employee will become a spy or google will be hacked and your emails/files will be copied then by all means encrypt with pgp

Answer 8

The only mainstream email encryption standards are PGP and S/MIME. Both work, both are effective. But neither will work with a webmail interface, since they're client-side. In fact, if you come across a mechanism that DOES work with the webmail interface, then you should be very suspicious of its security.

Most email providers (including GMail) support IMAP or POP3 along with SMTP. You can use this to hook up your mailbox with a desktop mail reader, such as Thunderbird. Then, you can use a client-side crypto engine (such as enigmail or the built-in S/MIME utilities) to access the cryptography functions.

Obviously both sides of the conversation need to be using the same crypto system, but that is always the case. Also, this is inherently inconvenient, and will probably always be so.

Finally, probably the simplest way to exchange encrypted content is as an attachment. Use a tool like 7-zip to create an encrypted package with the content you want to protect, and use a password that was pre-arranged out-of-band (such as by voice or in person).

Answer 9

Like other answers, Gmail is relatively safe since it is using HTTPS which means it encrypts your emails over TLS. If you want an added layer of security, that is what PGP is for. I suggest you can use something like a Google Chrome extension called FlowCrypt. It is an extension in Chrome that works perfectly with Gmail (https://flowcrypt.com/). It has a pretty easy setup and integration with Gmail is slick. I have tried and am using it well. There is also an app for FlowCrypt if you like to use it in mobile platforms.

You may also explore other solutions to use PGP like Protonmail, OpenPGP, etc. Just make sure that you share only your Public key to your correspondents in the emails, not your Private key. Private keys must never be shared with anyone.

Answer 10

The problem even with Office encryption (which has gotten significantly better when they moved to the XML format) is - if you are using a strong password, how will that be shared?

It seems like a simple option would be to use a commercial secure file exchange system, hosted on premise. Then, transfer could be encrypted using SSL, and his customers wouldn't have to deal with the encryption. Since it is on premise or on a dedicated server, there isn't a third party who could access the stored files.

But keep in mind that by doing that, he has to be able to manage that system and keep it secure. That is a risk as well.

It could be worth considering stuff such as Spideroak and Wuala, which are Dropbox-like services with client based encryption.

However, as an accountant, I would never want to have to ask my clients to install software. So basically, what would be the best would be a site such as Mega but more focused on security than it is now. It does client side encryption through Javascript in the browser, so while you have to trust them to deliver proper code to your browser, in theory they can't decrypt what is stored on their system.

Answer 11

In my opinion :

You and client both install a cryptool on their machine from

Download cryptool

both of you should learn how to use it

Learn cryptool with the help of video from youtube.com

then you may share some keys or number of steps to encrypt and decrypt the message.

Write your mail on cryptool and then encrypt the mail as per the procedure shared between two of you. and then copy the encrypted code to gmail text field of gmail's compose mail.then send to the client.

Client get the encrypted message they have to copy the encrypted message and then put it on crypt tool and follow the steps to decrypt the message to retrieve the original message.

I know this procedure is little bit long but by following it you will be 100% secure.