您假设文档必须通过电子邮件发送。听起来您只是在发送电子邮件（smtp）时防止被拦截。如果是这种情况，您只需要安全传输，而不必由最终用户处理加密。

您不能让他们从您通过 SSL 控制的 Web 服务器下载文档吗？您仍然需要以某种方式向他们提供 URL 和密码，但至少您可以从网络服务器中删除该文档。无论如何，他们将拥有文档的明文版本，因此您是否在网络服务器上保持明文并不重要，而是在密码后面。您可以控制访问权限并在他们获得后将其拉下。

关于 MS Office 安全性，不要使用 Office 2003。密钥长度被限制为 40 位，这仍然需要一些工作，但从技术上讲可以暴力破解。

我查看了 Office 2007 文件加密，它似乎很合适。很难确定，因为据我所知，该规范不是公开的（如果有人知道不同，我很想看看），但有一些文档。

密钥长度和密码选择是适当的。2007 Word 文件 (.docx) 现在是基于 XML 的。文件加密留下了一些可用的标头信息（用户将知道它是一个 .docx 文件和文件名），以及文件的指纹（这样如果密钥输入错误，它就有与之匹配的内容） ，但文件本身的内容是加密的。

如前所述，使用 PGP 创建 SDA（自解密存档）似乎完全符合您的标准，但我相信它仅适用于 PGP（$$$）而不是 GPG（免费）。如果你有实际的 PGP，我会走那条路。否则，使用 Word 进行文件加密似乎是安全的。

啊-这样一个长期存在且棘手的问题:)

很大程度上取决于你的“威胁模型”——你担心谁、担心什么以及信任谁。听起来您在获得文档后并没有在寻找加密，而只是在传输过程中。正如我在上面的评论中指出的那样，我认为您会关心您的消息的隐私以及文档名称的隐私和文档本身在传输过程中的隐私。

您可能可以指望的一件事是您的浏览器对 TLS 的合理支持。因此，如果有一个安全的 Web 服务提供商始终使用你们都信任的 https，那就可以了。但是您可能不想信任，例如，国家控制的 ISP 或在一个压迫国家的移动提供商。例如，参见黑莓与阿拉伯联合酋长国的战斗。

例如，如果你们都有 gmail，并且总是使用 https 访问它，那可能会起作用。谷歌文档也可以通过 https 访问。当然，您可能不信任 Google，但您可能会信任许多其他网站（例如 fastmail.fm）。

如果你们都使用一些安全的点对点协议或即时通讯方案或手机平台，那可能比电子邮件更安全。

这是一个长期存在的问题，我已经看到了很多解决方案。

几个考虑

这是一次性交换还是定期交换？

如果它是一次性交换，那么通过带外机制（例如，SMS 文本消息、通过电话口头、亲自）传达的密码/密码就足够了。

如果它是定期传输，那么这很可能不切实际，因此此时的一个选择是拥有一个预设的密码列表（再次在带外通信）并以预定的时间间隔进行处理。

从将文档传递给其他人的角度来看，这在很大程度上取决于他们安装了哪些软件以及用于进行传输的传输上的阻止/过滤。

自解密档案可以工作，但一些电子邮件系统会阻止附件中的可执行内容（如果系统纯粹在文件扩展名上工作，重命名文件会有所帮助）

加密的 MS Office 文档，如果它是现代版本并且所选的加密选项很好，则工作得相当好。正如您所提到的，由于旧版本的 Office 加密功能较弱，可能存在一些感知问题，但我不知道这是最新版本的问题（他们使用具有强大密码的 Microsoft CryptoAPI）

加密的 ZIP 档案，同样只要它是最新版本的软件（旧的 zip 加密不是很强大）。