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?

  • 2
    So you want an encryption scheme that both he and all of his clients would be able to use - presumably with varying levels of technical know-how, and requiring little or no support on his behalf?
    – Paul
    Commented Oct 14, 2011 at 4:49
  • in an ideal world, yes. was thinking something like dropbox but I'd think you'd want to encrypt before it's also on dropbox's servers. Maybe I'm a little paranoid but don't want to trust them on that.
    – timpone
    Commented Oct 14, 2011 at 4:53
  • Yeah exactly, it still requires the customer to be savvy enough to deal with decrypting and encrypting.
    – Paul
    Commented Oct 14, 2011 at 4:57
  • y - I agree that ain't going to happen.
    – timpone
    Commented Oct 14, 2011 at 5:10
  • 2
    How does the accountant send paper documents to clients? That may help us estimate their acceptable risk level. Commented Jul 11, 2012 at 14:56

11 Answers 11


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.

  • 1
    Also note that when you send mail to a non-gmail address, then you are at the mercy of the receiving provider(s).
    – tdammers
    Commented Oct 15, 2011 at 15:45
  • 2
    I wouldn't assume that gmail - to - gmail doesn't involve public internet. It shouldn't but it could
    – timpone
    Commented Oct 18, 2011 at 0:14
  • Useful information also here: security.stackexchange.com/questions/13217/…
    – Iszi
    Commented Jul 11, 2012 at 17:15

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.


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).

  • so file is uploaded via https, store in accellion, and then a msg is sent to other user telling him / her that they have a message? All msg transfer over https and like a session id for login to only allow access to the file of interest. That sounds pretty good.
    – timpone
    Commented Oct 14, 2011 at 5:09
  • 1
    "The customer receives the email, and clicks the link to download via https the file." What if someone else clicks on the link?
    – curiousguy
    Commented Oct 21, 2011 at 21:06
  • agreed - suffers from the reset password attack. Only as secure as email which we said before is insecure
    – timpone
    Commented Mar 21, 2012 at 20:09
  • 1
    @timpone After clicking the link, the user must have an account to access the file. These products provide many methods of ensuring the account is created and accessed securely. Please do research rather than stating assumptions.
    – Paul
    Commented Mar 21, 2012 at 23:27

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.


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.


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


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).


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.


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

$ 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.

enter image description here


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.

  • 2
    What exactly makes you think gmail would be relatively safe? This completely depends on the threat model. If google cannot be trusted, TLS is not a valid point and shouldn't be considered any more secure than pastebin, for example. TLS and PGP are not layers of security for the same threat, they migitate vastly different threats.
    – Tobi Nary
    Commented Feb 8, 2019 at 13:23
  • My bad explaining that TLS and PGP are preventing different threats. TLS is for transporting data across the network. PGP is for securing files. Well, like what the others pointed out 'trust' depends on the person using Gmail. I know that TLS can also be bypassed with SSL-stripping, but that is another topic. My main point is TLS is relatively safe assuming it has been implemented and deployed properly. Sorry for the confusion there, got confused with PGP since it is also sort of an added encryption used in emails. I failed to mention earlier that it is used mostly for files as its main usage.
    – warfreak92
    Commented Feb 11, 2019 at 15:54

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.

  • It seems that CrypTool is designed for learning cryptography, not for commercial use?
    – grawity
    Commented Oct 14, 2011 at 10:54
  • Just remember that you get what you pay for, especially with encryption. Don't go cheap, your clients will refuse to use it. That's what happened when my last employer went cheap with trend micro.
    – Brad
    Commented Jul 11, 2012 at 18:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .