我们现在不太确定该怎么称呼它，所以我们在标题中用混合名称来称呼它 Microsoft Office 365中.
（“Office”这个名称作为 Microsoft 的文字处理、电子表格、演示和协作应用程序的集合名词正在 杀死了 在接下来的一两个月内，变成简单的“Microsoft 365”。）
我们确信人们会继续使用单独的应用名称（Word, Excel, PowerPoint中 和朋友）和套房的绰号 办公 多年来，尽管该软件的新手最终可能会知道它是 365，在删除无处不在的 Microsoft 前缀之后。
您可能知道，Office 独立应用程序（您实际安装在本地的应用程序，因此您不必上网处理您的东西）包括他们自己的选项来加密保存的文档。
这应该增加一个额外的安全层，以防您以后意外或设计与不应该接收它们的人共享这些文件中的任何一个 - 在通过电子邮件共享附件时很容易错误地做到这一点。
除非并且直到您还向收件人提供了解锁文件所需的密码，否则对他们来说，这只是切碎的卷心菜。
当然，如果您将密码包含在电子邮件正文中，您将一无所获，但如果您对通过其他渠道共享密码稍微谨慎一点，您就为自己赢得了一些针对流氓的额外安全保障、窥探者和无所事事者可以轻松访问机密内容。
聚光灯下的OME
或者你有吗？
根据 研究人员 在芬兰网络安全公司 WithSecure，您的数据受到的保护可能比您合理预期的要少得多。
测试人员使用的功能就是他们所说的 Office 365 邮件加密或 OME 简而言之。
我们没有在这里复制他们的实验，原因很简单，核心 Office，对不起，365 产品不能在我们用于工作的 Linux 上原生运行。 网页版的Office工具没有完整应用的功能集，所以我们可能得到的任何结果都不太可能与大多数Office的商业用户，啊，365配置Word，Excel，Outlook的方式一致和他们的 Windows 笔记本电脑上的朋友。
正如研究人员所描述的：
宣传此功能是为了允许组织以安全的方式在组织内部和外部的人员之间发送和接收加密的电子邮件。
但他们也指出：
不幸的是，OME 消息在不安全的电子密码本 (ECB) 操作模式下被加密。
欧洲央行解释
解释。
许多加密算法，特别是 高级加密标准 OME 使用的 AES 或 AES 就是所谓的 分组密码，它一次打乱较大的数据块，而不是按顺序处理单个位或字节。
一般来说，这应该有助于提高效率和安全性，因为在驱动算法的加密曲柄的每一圈，密码都有更多的输入数据来混合切碎和液化，而且每一圈都让你走得更远通过您要加密的数据。
例如，核心 AES 算法一次消耗 16 个输入明文字节（128 位），并在加密密钥下对该数据进行加扰以生成 16 个加密的密文输出字节。
（不要混淆 块大小 密钥大小 – AES 加密密钥的长度可以是 128 位、192 位或 256 位，具体取决于您希望它们猜出的可能性有多大，但每次算法“启动”时，所有三种密钥大小都适用于 128 位块。）
这意味着如果您选择一个 AES 密钥（无论长度如何），然后直接在一块数据上使用 AES 密码……
…然后 每次获得相同的输入块时，都会获得相同的输出块.
就像一本真正庞大的密码本
这就是为什么这种直接操作模式被称为 欧洲央行， 短缺 电子密码本，因为这有点像拥有一本巨大的密码本，可以用作加密和解密的查找表。
（在现实生活中永远无法构建完整的“密码本”，因为您需要存储一个由 2128 16 字节条目 对于每个可能的键.)
不幸的是，尤其是在计算机格式的数据中，由于所使用的文件格式，某些数据块的重复通常是不可避免的。
例如，通常会填充数据部分以使其排列在 512 字节边界（写入磁盘时的常见扇区大小）或 4096 字节边界（保留内存时的常见分配单元大小）上的文件通常会生成带有零字节的长时间运行。
同样，包含大量样板文件的文本文档（例如每页上的页眉和页脚，或重复提及完整的公司名称）将包含大量重复。
每次重复的明文块恰好在 AES-ECB 加密过程中排列在 16 字节边界上时，它就会因此出现在加密输出中 作为完全相同的密文.
因此，即使您无法正式解密密文文件，您也可以从中做出立即的、破坏安全性的推论，这要归功于输入中的模式（您可能知道或能够推断出）或猜测）保留在输出中。
这是一个示例，基于我们近九年前发表的一篇文章，当时我们解释了为什么 Adobe 现在臭名昭著地使用 ECB 模式加密来“散列”其用户的密码是 不是一个好主意:
权利。 使用 AES-128-ECB 加密的图像数据。
请注意输入中纯白色的像素如何可靠地在输出中产生重复图案，而蓝色部分保持一定规律，因此原始数据的结构是显而易见的。
在这个例子中，原始文件中的每个像素正好占用 4 个字节，因此输入数据中从左到右运行的每个 4 像素长度为 16 个字节，这与每个 16 字节的 AES 加密块完全对齐，从而强调“欧洲央行效应”。
匹配密文模式
更糟糕的是，如果你有两份文件，你知道它们是用相同的密钥加密的，而你恰好有其中一份的明文，那么你可以查看你得到的密文 不能 解密，并尝试将其中的部分与您在密文中的模式进行匹配 能够 解密。
请记住，如果您已经拥有解密形式的第一个文档，则不需要密钥来“解密”第一个文档 - 毫不奇怪，这被称为 已知明文攻击.
即使只有少数匹配的明显无辜的文本本身并不是秘密数据，对手通过这种方式提取的知识也可能成为知识产权间谍、社会工程师、法医调查人员等的金矿。
例如，即使您不知道文档的详细信息指的是什么，通过在多个文件中匹配已知的明文块，您也可以确定一个明显随机的文档集合：
- 都寄给了同一个收件人， 如果每个人的顶部有一个共同的称呼。
- 参考同一个项目， 如果有一个唯一的识别文本字符串不断弹出。
- 具有相同的安全等级， 如果你热衷于关注那些显然比其他“更秘密”的东西。
怎么办呢？
不要使用欧洲央行模式！
如果您使用的是分组密码，请选择一个 分组密码操作模式 说：
- 包括所谓的 IV 或初始化向量， 为每条消息随机且唯一地选择。
- 刻意安排加密过程 这样重复的输入每次都会出现不同的结果。
如果您使用的是 AES，那么这些天您可能想要选择的模式是 气相色谱法 （伽罗瓦计数器模式），它不仅每次使用 IV 来创建不同的加密数据流，即使密钥保持不变，而且还计算所谓的 消息验证码 (MAC) 或加密校验和，同时对数据进行加扰或解密。
AES-GCM 不仅意味着您可以避免重复的密文模式，而且您总是会得到一个“校验和”，它会告诉您刚刚解密的数据是否在途中被篡改。
请记住，一个不知道密文实际含义的骗子可能仍然能够欺骗您相信一个不精确的解密，而无需知道（或关心）您最终得到什么样的错误输出。
在解密过程中根据相同的密钥和 IV 计算出的 MAC 将有助于确保您知道收到的密文是有效的，因此几乎可以肯定您已经解密了最初在另一端输入的内容。
或者，使用专用的 流密码 它会生成伪随机的逐字节密钥流，允许您加密数据而无需一次处理 16 个字节（或任何块大小）。
AES-GCM 本质上将 AES 转换为流密码，并以 MAC 的形式添加身份验证，但如果您正在寻找专门设计用于这种方式的专用流密码，我们建议 Daniel Bernstein 的 ChaCha20-Poly1305 （Poly1305 部分是 MAC），详见 RFC 8439.
下面，我们展示了使用 AES-128-GCM 和 ChaCha20-Poly1305（我们在这里丢弃了 MAC 代码）得到的结果，以及由 95,040 RGBA 字节（330×72，每像素 4 字节）组成的“图像” Linux 内核伪随机生成器。
请记住，仅仅因为数据看起来非结构化并不意味着它是真正随机的，但如果它看起来不是随机的，但它声称是加密的，那么您不妨假设留下了一些结构，并且加密是怀疑：
接下来会发生什么？
根据 WithSecure，微软不打算修复这个“漏洞”，显然是出于向后兼容 Office 2010 的原因……
旧版 Office (2010) 需要 AES 128 ECB，Office 文档仍以这种方式受到 Office 应用程序的保护。
…和…
[WithSecure 研究人员的] 报告不被认为符合安全服务标准，也不被认为是违规行为。 没有进行代码更改，因此没有为此报告发布 CVE。
简而言之，如果您目前依赖 OME，您可能需要考虑将其替换为敏感消息的第三方加密工具，该工具独立于创建这些消息的应用程序对您的数据进行加密，因此独立于内部加密工作Office 范围内的代码。
这样，您可以选择现代密码和密码操作的现代模式，而不必退回到 Office 2010 中内置的老式解密代码。
我们如何在文章中制作图像 从 sop330.png 开始，您可以通过从最顶部的图像裁剪清理后的 SOPHOS 徽标、删除 2 像素蓝色边界并以 PNG 格式保存来为自己创建。 图像最终应为 330x72 像素大小。
使用 ImageMagick 转换为 RGBA： $ convert sop330.png sop.rgba 输出为 330x72 像素 x 4 字节/像素 = 95,040 字节。
=== 使用 Lua 和 LuaOSSL 库进行加密（Python 有一个非常相似的 OpenSSL 绑定）： -- 加载数据 > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- 创建密码对象 > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') --初始化密码和 IV -- AES-128-ECB 需要 128 位密码，但没有 IV -- AES-128-GCM 需要 128 位密码和 12 字节 IV -- ChaCha20 需要 256 位密码和a 12-byte IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- 使用三种密码加密文件数据> aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- 流密码逐字节产生输出， -- 所以密文的长度应该与明文相同> gcmout:len() 95040 > chaout:len() 95040 -- 我们不会在这里使用 GCM 和 Poly1305 的 MAC 代码， -- 但是每个密码产生一个 128 位（16 字节）的“校验和”——用于在解密完成后验证解密，——检测输入密文是否被破坏或被黑客攻击——（MAC 取决于密钥，因此攻击者无法伪造）> base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56ef - 直接从 /dev/random > rndout = 创建一个 95040“图像” misc.filetostr('/dev/random',#fdat) -- 全部保存 -- 请注意，我们明确截断了 AES-ECB -- 将密码输出分组到所需的确切图像长度，因为 -- ECB 需要填充以匹配块大小的输入大小 > misc.strtofile(aesout:sub(1,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === 要在常规图像查看器中加载文件，您可能需要将它们无损转换回 PNG 格式： $ convert -depth 8 -size 330x72 aes .rgba aes.png $ 转换 -depth 8 -size 330x72 gcm.rgba gcm.png $ convert -depth 8 -size 330x72 cha.rgba cha.png $ convert -depth 8 -size 330x72 rnd.rgba rnd.png === 假设加密过程会扰乱每个 RGBA 像素中的所有四个字节，生成的图像具有可变的透明度（A = alpha，透明度的缩写）。
您的图像查看器可能会决定显示这种带有棋盘背景的图像，它看起来像是图像的一部分，但实际上不是。 因此，我们使用原始图像中的 Sophos 蓝色作为加密文件的背景，以使它们更易于查看。 因此，整体蓝色色调不是图像数据的一部分。
