邮箱加密与GPG签名#

---
创建日期: 2020-02-12
---
由于工作邮箱出问题，对加密、签名的探索。

邮箱加密#

起因是：账号从apa域到emea域后，加密邮件不能显示了，怀疑账号有了新的密钥对。 同时出现的状况还有：系统登录时，提示没有找到一组文件夹下的密钥。

旧账号的用户文件夹是[username]，新账号是[username.emea]。 顺着那个提示，我也进入了旧账号的文件夹（给权限），却没有看到任何“PGP”的文件夹。 我还试着创建了两个空文件，没有效果。

就这么僵持了好久，反正平常也没人会发加密邮件。 就这两天，我也忘了为什么想起试gpg的命令，孰因孰果，忘了。 最终原因，密钥存在c:\userdata\[username]\下，新的账号没有这个文件夹权限，所以没找到。 提示的是 c:\user\[username]\，（user和userdata是同一个文件夹），我看错了，给了c:\users\[username]\的权限。 （本该是有个[username.emea]的文件夹，但是却没有。userdata下的用户文件夹，主要应该是内部网络同步用的，所以应该和同步软件有关系。

可另一方面，即使打通了这一条道路，邮件依然无法查看。 想来服务端的公钥应该是随新账号更新了，旧密钥不能使用。

同步机制这个事情，之前就让我很好奇。 既然一个账号会在不同的电脑上登录，甚至会使用网页邮箱。那总不能只在一台电脑上有密钥存储。 先抛开网页查看问题，密钥其实在各个电脑与服务器间同步，那私钥有什么意义？ 如果每台电脑有自己的私钥，那邮件的加密方式是什么？

加密邮件是可以发送给多个人的，本着不浪费的原则，发送邮件的时候，发出的是同一个内容吗？（一次加密，多份独立发出） 如果独立发出不同的加密邮件，那留在发件箱里的又是哪一份呢？

可以问如下几个问题：

  1. 不同电脑上存在的密钥对是一样的吗？

    这个已验证，是一样的。所以密钥在不同电脑间同步。

  2. 账号转移到新域下，有新的密钥对吗？

    等待验证，在LMM的电脑上查找密钥对，导入并对比，看是否与TNJ相同。 基本可以确认是一样的，因为连接上公司网络后更新了密钥，添加新UID（密钥不变）。

  3. 群发的加密邮件，收件人列表上的所有人是收到相同的邮件吗？

    可以有两种机制：

    1. 针对每个收件人，使用其公钥加密邮件，单独发送。如此则是不同的邮件。

      这个的问题在于，那么，在己方的收发件箱中，邮件不是加密的。

    2. 使用相同的密钥对称加密邮件，然后对这个密钥本身用收件人的公钥独立加密，收件人可以根据自己的信息解密得到邮件密钥。

      这其实只是个协议的过程，把内容加密，收件人信息不加密。

    认为第一个的概率大，简单。

  4. 在outlook客户端，存储的邮件是加密过后的吗？

    使用outlook导出（拖曳到桌面）的加密邮件，可以直接打开（或者记事本打开能看到邮件内容）。 所以要么导出自动解密，要么邮件存储的已经是解密过后的。

    验证的方法：

    1. 发送加密邮件

    2. 收件人在网页上查看（假设网页邮箱没有密钥，不会解密）

    3. 收件人用客户端打开（客户端有密钥，能解密）

    4. 回到网页上查看邮件是否解密

    回去的原因是，如果客户端自动解密，并且更新了邮件服务器的内容（删除加密副本，替换成解密后的），什么POP3/SMTP之类的协议。 如果是这样，好像加密真的没什么意义，反正服务器上是明文的。

    答案是：

    邮件是加密存在于服务器上的，网页无法查看，邮件解密由插件自动完成了。 如果阻碍插件运行，就又看不到了，（所以客户端也是加密存储的）。 另外，加密部分是以附件形式存在的，smime.p7m，其余部分就是正常邮件。 既然是附件形式存在，那其余就简单了，只是这个附件不能简单下载。

  5. 话说，加密发送给外部邮箱，没有公钥怎么办？

    发不出去 :D

    Sign 是可以的，消息明文，附件一个签名文件。

GPG签名#

之前就看到过各种签名相关的东西，电子签名、镜像文件下载时候的哈希值签名、签名的文件（一堆横线的那种--）。 我没验证过，也不知道怎么验证。 不明白签名的作用是什么，隐约觉得算是一种内容保护机制。 内容保护，例如原创性证明（著作权）、内容加密？

认知#

gpg里有各种签名选项，测试认知过程就忽略了。直接说认知：

签名的作用不是隐藏信息，或者著作权保护（我以前有这种误解）。 签名是为了防治消息被篡改。（也表明对被签名的消息内容负责） 使用私钥对文档进行签名，确保文档没有被更改。 验证过程需要签名者的公钥。

签名和内容有关，需要互相验证。 不同文件会有不同的签名，甚至相同文件也可以有不同签名（比如和时间戳或者初始盐值有关）。 （因为说是签名嘛，我想那签名应该是独立存在的，毕竟人的签名和内容本身没什么关系，所以也造成了理解错误）

签名使用私钥，所以验证签名前提是获得了正确的公钥。 这就需要有公信力的公钥，能确保这个公钥代表签名的人。

单单从消息不被篡改来说，哈希值也能起作用。 哈希值是消息的指纹，消息如果被修改，哈希值也会变。 例如下载镜像文件的时候，经常会看到该文件的哈希值信息，确保下载内容不会被更改或者下载过程出错。 但现在常常伴随哈希值出现的，还有哈希值的签名文件。（哈希值信息文件与签名文件独立的情形，以及哈希值信息和签名存在同一个文件中的情形，都有存在） 因为哈希值本身也可能被恶意篡改，内容就不可靠了。

GPG的签名选项#

--sign:
    生成二进制".gpg"，包含信息（message）和签名（signature）
    信息部分可以使用gpg解码，还原文件
    加"-a"只有消息部分（但应该相当于base64效果）
--clearsign:
    生成ASC".asc"，包含信息和签名
    加"-a"效果相同
--detach-sign
    生成二进制".sig"，只包含签名部分
    验证的时候，需要信息文件存在
    加"-a"效果不错，只有签名部分
因 多变量微积分 而起   使用COM