TLS 协议前置知识

区分一些常见的术语

如：Hash、哈希、杂凑、散列、单向函数、摘要、指纹、MD5、SHA-1、MAC、CMAC、HMAC、签名、加密、编码。

Hash

中文直译哈希；中文意译散列、杂凑。
单向函数

由于哈希过程是单向的，所以哈希函数又叫做单向函数。
摘要

哈希生成的那一串哈希值叫摘要或叫指纹。
MD5

众多哈希算法中的一种。
SHA-1

众多哈希算法中的一种。
MAC

Message Authentication Code 消息验证码。
CMAC

Cipher-based Message Authentication Code 基于分组加密的消息验证码。
HMAC

Hash-based Message Authentication Code 基于哈希的消息认证码。
加密

有加密就要有解密，像 MD5 等单向函数不是加密，像 Base64 等编码不需要密钥就能还原也不是加密。
签名

非对称加密的逆运用，一般先哈希消息生成摘要，然后私钥“加密”摘要生成签名，最后用公钥“解密”签名得到原摘要，再哈希收到的消息得到新摘要，对比两摘要是否一致可验证签名。
编码

将某一集合内的字符根据对应关系替换成另一集合内的字符。

Hash、MAC、CMAC、HMAC、签名的区别

Hash

MAC、CMAC、HMAC、签名的目的不是为了加密让别人看不懂，而是为了证明（如证明消息没被修改，证明消息就是某人发送的），直接对整个消息进行签名或生成 MAC 是没必要的，一是“加密”浪费性能（特别是非对称加密），二是传输的数据量直接翻倍，所有一般先哈希生成摘要后再对摘要签名或生成 MAC。
MAC

用来确保消息的完整性，可以通过分组算法或哈希函数等构造。不管是用分组算法构建还是哈希函数构造都会用到哈希函数和一个密钥，所以又叫带密钥的哈希。
CMAC

CMAC 是使用分组算法（例如 AES 和 DES）构造 MAC 的一种方法，例如 AES-CMAC 将 AES 分组密码转换为 MAC。
HMAC

HMAC 是使用哈希函数（例如 MD5 或 SHA-256 ）构造的 MAC 的一种方法。因此有 HMAC-MD5 和 HMAC-SHA256 等特定的 MAC 算法，就像快速排序是特定的排序算法一样。
签名

签名是非对称加密的逆运用。和 MAC 的区别在于只能一人签名，但多人能验签。MAC 只要持有密钥的人就能生成 MAC 或验证 MAC。

MAC 只能保证消息的完成性不能保证消息的不可否认性，但签名两者都可以保证。因为 MAC 使用对称加密体制，会话双方都能生成 MAC 或验证 MAC ，只能确定消息是持有密钥的人发的，不能明确是哪一个发的；数字签名使用的是非对称加密体制，只有拥有私钥的人才能签名，拥有公钥的人都能验签，那么就能证明消息一定的拥有私钥的人发的。

Hash、CMAC、HMAC、签名的生成过程

上述的描述可能还是会有点生涩，来看下具体的过程来区分他们的区别

Hash

Hash(消息内容) -> 摘要；
CMAC

生成：Hash(发送的消息内容) -> 摘要；分组密码加密(摘要，对称密钥) -> MAC1；

验证：Hash(收到的消息内容) -> 摘要；分组密码加密(摘要，对称密钥) -> MAC2；对比两 MAC 是否一致；
HMAC

生成：Hash混入密钥(发送的消息内容，对称密钥) -> MAC1；

验证：Hash混入密钥(收到的消息内容，对称密钥) -> MAC2；对比两MAC是否一致；
签名

生成：Hash(发送的消息内容) -> 摘要；非对称加密(摘要，私钥)->签名；

验证：Hash(收到的消息内容)->摘要1；非对称解密(签名，公钥)->摘要2；对比两摘要是否一致；

一些常见的算法

哈希

MD5

SHA 家族：SHA-1，SHA-256，SHA-384等
对称加密

DES

AES 家族：AES-256-CBC，AES-256-GCM等
非对称加密

基于大质数分解难题的：RSA

基于离散对数难题的：ElGamal

基于椭圆曲线离散对数难题的：ECC
签名（非对称加密算法的逆运用）

基于大质数分解难题的：RSA

基于椭圆曲线对数难题的：ECDSA
密钥交换

RSA 密钥传递（不能完美向前安全）

DHE 密钥协商（性能没椭圆曲线的好）

ECDHE 椭圆曲线离散对数密钥协商

总结：

非对称加密算法的普及已有原来的基于大质数分解难题的 RSA 转变成性能更好的基于椭圆曲线离散对数难题的 ECC，签名方法由于历史原因 RSA 依然会经常使用。

密钥交换算法如果不是故意不保证完美向前安全，一般都会选择使用性能好又能保证完美向前安全的 ECDHE

一句话总结

哈希

任意长度输入，固定长度输出，输入和输出不可逆。
对称加密

加密和解密用同一密钥。
非对称加密

公钥加密，私钥解密。
签名

私钥签名(“加密”)，公钥验签(“解密”)。

注:

RSA中两密钥数学上没区别，实际中实现时一般有区别；其他非对称加密算法的公钥和私钥数学上一般有区别，实际中实现时也有区别。所以非对称加密公钥私钥是否可互换问题有待商讨。

RSA 非对称加密的原理

应用

TLS 中传递对称加密密钥

TLS 中校验证书签名
理论
- 参考
  
  RSA算法原理（一）
  
  RSA算法原理（二）
- 质因数
  
  指能整除给定正整数的质数，求某个数的质因数可以用短除法。
  Code
  1
  2
  3
  4
  5
  6
  7
  for (long i = 2; i <= n; i++) {
  if (n % i == 0) {
  set.add(i);
  n = n / i;
  i--;
  }
  }
- 互质
  
  两个没有共同质因子的正整数，不是质数也可以构成互质关系：如 8 和 9
- 1 既不是质数也不是合数，所以 1 和任何数互质(包括自己)
- 模反元素
  
  如果两个正整数 a 和 n 互质，那么一定可以找到至少一个整数 b，使得 a*b - 1 被 n 整除，b 叫做 a 对于 n 的模反元素。比如 3 和 11 互质， (3 × ？-1） % 11 = 0，求得 3 对于 11 的模反元素为 4，可以用欧拉定理或扩展欧几里得算法去求
- 欧拉函数 φ(n)
  
  任意给定正整数 n，在小于等于 n 的正整数之中，有多少个与 n 构成互质关系的数
  
  φ(n) = n * (1 - 1/p₁) * (1 - 1/p₂) * (1 - 1/p₃) * … * (1 - 1/p_n)
  
  其中 p₁ ~ p_n 是 n 的质因数，如 120 = 2×2×2×3×5，120 的质因数为 2 3 5。
步骤

步骤1）随机选择两个不相等的质数 p 和 q

步骤2）计算 p 和 q 的乘积得到 n

步骤3）计算 n 的欧拉函数 φ(n)

步骤4）随机选择一个整数 e，条件是 1 < e < φ(n)，且 e 与 φ(n) 互质。

步骤5）计算 e 对于 φ(n) 的模反元素 d

步骤6）将 n 和 e 封装成公钥(n,e)， n 和 d 封装成私钥(n,d)。

步骤7）加密，已知公钥(n,e)：原文^e = 密文 % n -> 密文 = …

步骤8）解密，已知私钥(n,d)：密文^d = 原文 % n -> 原文 = …

Diffie-Hellman 密钥协商原理

应用

TLS 中 DH 可以在全程不加密的传输条件下，双方能协商出(非传递)一个对称加密密钥。
理论（基于普通离散对数，椭圆曲线离散对数这里不再深入）

已知 5^x = 25，那么 x = log₅25 = 2，求 x 的过程叫对数运算，对数运算非常容易，即使在数字很大的时候。

已知 2^x % 11 = 8，求 x 的过程称为离散对数（这里底数 2 和 11 都不是随便选的，有要求），该计算就很困难，在模数（11）很大时几乎是不可能的运算。

而 DH 秘钥交换就是利用了这种离散对数计算非常困难的特性来设计的。

公式里的 % 是取模运算，取模运算有几条基本的定律如下：

(a+b) % p = (a%p + b%p) % p

(a*b) % p = (a%p * b%p) % p

(a^b) % p = (a%p)^b % p

根据上面的公式，可以推导出一个非常重要的公式：

G^ab % P = (G^a % P)^b % P = (G^b % P)^a % P
步骤

步骤1）发送方和接收方协商一个大质数 p 和 p 的一个原根 g（范围 [2,p-1]）；

步骤2）发送方秘密选择一个大随机整数 a（范围：[1, p-1]），计算 A = g^a % p，公开发送 A 给接收方；

步骤3）接收方秘密选择一个大随机整数 b（范围：[1, p-1]），计算 B = g^b % p，公开发送 B 给发送方；

步骤4）双方计算出密钥

发送方：S_a = B^a % p = (g^b % p)^a % p = g^ab % p；

接收方：S_b = A^b % p = (g^a % p)^b % p = g^ab % p；

可知：K = S_a = S_b；

知道p、 g、 A、B 不能计算出密钥 K ，除非还至少知道 a 或 b 其中一个；

严格来说 a 和 b 的取值范围是 [1, p-2]，因为 p 是质数 g 是 p 的一个原根，根据费马小定理 g^p-1 % p = 1，如果 A 计算结果是 1 的话，a 就一定等于 p-1。实现时有些情况 p 和 g 都是在 rcf 中规定好了，一般不用自己随机选了。
例子

假如 p = 23，g = 5

发送方选取的秘密数字 a = 6，那么 A = 5⁶ % 23 = 8，将 A 发送给接收方

接收方选取的秘密数字 b = 15，那么 B = 5¹⁵ % 23 = 19 ，将 B 发送给发送方

发送方计算出的密钥 S_a = 19⁶ % 23 = 2

接收方计算出的密钥 S_b = 8¹⁵ % 23 = 2

使用 RSA 密钥传递和使用 DH 密钥协商时的中间人攻击

RSA 密钥传递

RSA 服务端在下发公钥给客户端的时候，会被中间人把公钥给替换掉。

从而对客户端假装自己是服务器骗到客户端的对称密钥。对服务端假装自己是客户端，自己生成一个对称密钥和服务端通信。两边通信的密钥中间人都拿到了。

防止中间人攻击需要 CA 对下发的公钥进行签名才行，客户端去找 CA 验证签名。
DH 密钥协商

DH 在交换 A 和 B 的时候，会被中间人把 A 和 B 都替换掉。

也就是对客户端替换掉服务端发来的 B，自己和客户端协商了一个对称密钥。对服务端替换掉客户端发来的 A，自己和服务端协商了另一个对称密钥。两边通信的密钥中间人都拿到了。

防止中间人攻击，且如果要双向认证，需要客户端在传递 A 和服务端在传递 B 时，双方各自的公钥分别对 A 和 B 进行签名才行（TLS 中客户端也可用向服务端发送证书的）。

但一般不需要双向认证，只要客户端验证服务端即可，如服务器用私钥签自己的 B，然后客户端用服务器的证书中公钥验证 B，服务器的证书已由 CA 来保障，然后客户端直接把自己的 A 传给服务端。

单向认证有什么风险吗？中间人只替换掉 A 或 B 其中一个是没有用的，这样客户端和服务端两边协商出来的对称密钥不一致，除非有特定需求否则普通场景下单向认证是安全的。

RSA 传递密钥和 DH 协商密钥的异同

RSA 和 DH 都不能防止中间人攻击，除非引入 CA 后，两者才能防止中间人攻击。

DH 不用于加密，只用于密钥协商，RSA 用于加密或签名，RSA 受 DH 思想启发而来。

RSA 在传递对称密钥回去给服务器的时候用服务器的私钥来解密对称密钥。

DH 不直接传递对称密钥，握手全程不需要加密。

DH 能保证完美向前安全，RSA 不可以。

DH 是如何保证完美向前安全的？

什么叫完美向前安全

即使我们储存了以前所有的通信数据，现在当密钥丢失后，以前的所有数据也是安全的(不能解密)。
是如何保证的

假设某人在 A-B 通信期间，截获并存储了所有的通信过程。

如果是用 RSA 传递密钥，那么当 B 的私钥泄露以后，M 就可以解密所有数据。因为对称密钥一开始也是使用公钥加密后再传到 B 的，M 拿 B 的私钥后解开就能得到对称密钥。然后用对称密钥解开其他所有通信内容。

如果是用 DH 协商生成密钥，那么当 B 的私钥泄露以后，因为对称密钥并没有传递，而是客户端和服务器两边计算生成，那段截获的数据中也就没有包含对称密钥，也就没法解密通信内容。除非能把协商时服务端的随机数或客户端的随机数中的其中一个拿到，就能根据截获的公开数据和找到的随机数计算出对称密钥。但是这两个随机数都是不保存的，生成对称密钥后就销毁了。所有 DH 是能保证向前安全的。

信息安全的五个特征

完整性
保密性
不可否认性
可用性
可控制性

场景一：（使用MAC保证消息完整性）

A 和 B 之间相互写信。A 向 B 写信，内容如下：

Code

亲爱的B：
  你好吗，最近过得怎样？
...................................................................................
......................................................................................................................................................................
................................................
                                                                        来自：A
                                                                        2018.11.19

送信员拿到 A 的信后，模仿其笔迹：

Code

亲爱的B：
  你好吗，最近过得怎样？我最近手头有点紧，能不能把一万块钱转到XXX支付宝账号，谢谢！
...................................................................................
......................................................................................................................................................................
................................................
                                                                        来自：A
                                                                        2018.11.19

为了防止这种情况发生，所以他们上次见面时秘密协商了一个对称加密的密钥

A 向 B 写信，内容变成了如下：

Code

亲爱的B：
  你好吗，最近过得怎样？
...................................................................................
......................................................................................................................................................................
................................................
                                                                        来自：A
                                                                        2018.11.19
                                                                     消息验证码：xxxxx

消息验证码生成： Hash(写信时的内容) -> 摘要1； 对称加密(摘要1，密钥) -> 消息验证码1；

B 收到信后： Hash(收到信时的内容) -> 摘要2；对称加密(摘要2，密钥) -> 消息验证码2；

如果消息验证码1和消息验证码2一致，则说明信的内容没有被修改过，否则不是。

场景二：（使用签名保证消息完整性和不可否认性）

一个的大师收了十个徒弟，大父每天写武林秘诀的信给各个徒弟，徒弟会根据信上的内容练功。

为了防止送信人使坏，如在信的最后添加：欲练此功，必先自宫。

根据场景一的方法，大师和徒弟十个人，秘密协商一个对称加密密钥，就可以防止送信人使坏了。

但这样只能防止送信人使坏，使用对称加密来生成消息验证码有一个弊端，就是双方都需要持有密钥，如果徒弟十个人中有的人也想使坏呢？或者有的徒弟不小心把密钥泄露了出去，怎么办？

这时候就得用非对称加密了，大师把非对称加密中两个密钥的任何一个自己留着，叫做私钥。然后把另一个密钥告诉十个徒弟，叫做公钥。（这里只是为了说明问题，私钥和公钥在非对称加密中还是有区别的）

签名生成： Hash(写信时的内容) -> 摘要； 非对称加密(摘要，私钥) -> 签名；

徒弟收到信后验证签名： 非对称解密(签名，公钥) -> 摘要1；Hash(收到信时的内容) -> 摘要2；

如果摘要1和摘要2一致，则说明信的内容是大师写的（不可否认性），且没有被修改过（完整性），否则不是。

场景三：(CA的预引入)

大师是个神秘人不能露面，也就是双方不能直接传递公钥，那又要怎样把公钥告诉徒弟呢？

直接写信告诉不行吧，送信人仿照大师的笔记，把大师真正的公钥给修成自己的了，然后写信时使用自己的私钥签名，徒弟收到信后拿着假的公钥验签，发现验证通过，其实并不是大师的原信。

大师想到：我不能和徒弟见面，但是我可以和我信得过的好朋友见面呀，于是将公钥送到好朋友手中，大师的徒弟们去找其好朋友拿公钥。

场景四：（CA和证书的引入）

诶，不巧的是这个朋友是朵交际花，她不光认识这位神秘大师，她还认识很多位神秘大师。

那岂不是这个朋友要保存很多大师的要发放给徒弟们的公钥呀，朋友说这个我不干，家里装不下那么多东西，要不你们这些大师看看这么着行不行。

我生成一个我自己的公钥和私钥，你们也不用自己生成你们的公钥和私钥了，告诉我你们的信息我来帮你们生成。

然后替你们写一封包含你们公钥的信，再用我的私钥对这封信签个名，这封信和你们的私钥将送到你们手上。

你们将我签过名的信寄给你们徒弟，接着你们各个徒弟来找我拿我的公钥，这样我就不用保存你们的公钥了，我只要保管好我自己的私钥就可以。

Code

徒弟们：
    我的公钥是：xxx，你用它来校验是否是我写的信。
                                                                          来自师父
                                                                         2019.04.01
                                                                        签名：朋友的签名

朋友签的这封信：Hash(信的内容) -> 摘要； 非对称加密(摘要，朋友的私钥)->签名；

徒弟们收到信后：非对称解密(签名，朋友的公钥)->摘要1；Hash(收到信时的内容)->摘要2；

如果摘要1和摘要2一致，徒弟们之后就可以拿信中写的公钥来验证收到的信是不是大师写的了。

这个朋友有一个高大上的名字叫作 CA：证书颁发机构 ，朋友帮大师们写的那封包含公钥的信又叫做证书。

（浏览器不能保证服务器传来的公钥（证书）一定是服务器的，需要 CA 来验证， CA 的公钥（证书）会内置到浏览器中）

场景五：（证书信任链）

这个朋友就这样每天帮着成百上千的大师生成公钥和私钥。有一天，大师朋友觉得一个人处理这么多事情累了，而且私钥一丢或泄露就麻烦大了。她在想能不能招几个马仔来帮自己替大师们生成公钥和私钥呀，自己管理马仔就好了。可是问题又来了，这些徒弟就只信得过大师这个朋友，信不过其他人怎么办？

大师朋友想到：大师的徒弟们还是自己来找她拿她的公钥

Code

1	朋友的公钥：xxx，徒弟自己提前拿到。

自己再为马仔生成公钥和私钥，然后替马仔写一封证明信，并用自己的私钥签上名，然后将这封信和生成的私钥交给马仔，马仔将这封信交给大师。

Code

大师们：
    我的公钥是：xxx，你用它来校验是否是我写的信。
                                                                   来自马仔
                                                                 2018.11.19
                                                          
                                                                 颁发者：朋友
                                                                 颁发给：马仔
                                                                 颁发者签名：朋友的签名

马仔再为大师生成公钥和私钥，然后替大师们写一封信给徒弟们，并用自己的私钥签上名，然后将这封信和生成的私钥交给大师，大师再将这封信和朋友为马仔写的证明信一起寄给徒弟。

Code

徒弟们：
    我的公钥是：xxx，你用它来校验是否是我写的信。
                                                                   来自师父
                                                                 2018.11.19
                                                          
                                                                 颁发者：马仔
                                                                 颁发给：大师
                                                                 颁发者签名：马仔的签名

徒弟要验证传来的师父公钥是否是真的，那么根据上面的信息去找马仔证明信中的公钥来验证。

验证通过后，徒弟要判断这个马仔是否是授权的？那么根据上面的信息去找朋友的公钥来验证。

此时朋友的公钥已经早已提前给到小弟手上，如果验证通过，则说明给的师父的公钥没问题。

如果马仔还想招小弟的话也类似，下一级的公钥是否是真的，是用上一级的公钥来验证的，直到验证到最顶级，而已经提前拿到了最顶级的公钥了(浏览器内置根 CA 的证书(公钥))

场景六（使用对称密钥保证消息的保密性）

徒弟看着信中的内容练功，突然有些东西看不明白，徒弟想写信请教师父，当然他也不想自己写的信被送信人看到或修改，场景五中已经拿到师父的公钥了，只要把信的内容用公钥加密就可以了，师父收到后用私钥解密就能看到徒弟的信。可是非对称加密性能堪忧呀，这个先不管能用就行。

有一天送信人来给大师送信，大师一看这送信人，不对呀，这人怎么骨骼精奇，走路姿势都像是我交给徒弟们的？原来送信人在给徒弟们送信时，偷偷看了信的内容学了起来。大师想，光徒弟写来的信加密了，这不行，得想办法给自己写的信也加密才行。

大师脑瓜一转，直接用自己的私钥“加密”，徒弟用公钥“解密”如何。大师发现这不放屁吗？公钥谁都能拿到，加个屁的密呀。

最后大师想到个两全其美的办法，既能解决徒弟使用非对称加密性能问题，又能解决自己也要加密的需求。那就是叫每个徒弟再生成某对称密钥，然后把密钥通过大师的公钥加密后传过来，大师用自己的私钥解开传过来的信，就可得到到信中的对称密钥了。以后每次再和这个徒弟写信时，两人都使用这个对称密钥加密和解密。

场景七（DH 协商对称密钥保证完美向前安全）

经过场景六徒弟和师父使用对称加密写信后，送信人就看不懂信的内容了。

送信人想：现在看不懂不代表以后看不懂，不管三七二十一先把你们的信全部抄下来（特别是徒弟传递对称密钥给师父的那一封），等那天大师驾鹤归去时，偷偷溜进大师家将它的私钥给偷了，然后用私钥解密徒弟传递对称密钥时的那一封信便可得到对称密钥，其他所有的信再用对称密钥解密就能看全部信的内容。这就叫不完美向前安全。

那有什么办法保证完美向前安全吗？由上面的 DH 密钥协商协议知道，徒弟可以不直接传递对称密钥给师父，而是徒弟和师父间先传递了四个公开数，且两人各自随机生成一个秘密数，各自的秘密数加上这四个公开数两人都能算出同一个数，那么算出的这同一个数就是对称密钥，然后立即销毁各自的秘密数。

这样，即使大师的私钥被偷了，那送信人拿不到这个对称密钥，因为根本就没有传输过这个对称密钥而是用秘密随机数计算得到的，而秘密随机数生成对称密钥后就销毁了。

签名和验签的详细过程

一般来说，不直接对消息进行签名，而是对消息的哈希值进行签名，步骤如下。

（1）对消息进行哈希计算，得到哈希值
（2）利用私钥对哈希值进行加密，生成签名
（3）将签名附加在消息后面，一起发送过去
（4）验证签名
（5）收到消息后，提取消息中的签名
（6）用公钥对签名进行解密，得到哈希值1。
（7）对消息中的正文进行哈希计算，得到哈希值2。
（8）比较哈希值1和哈希值2，如果相同，则验证成功。

RSA 的公钥私钥是否可互换问题讨论

公钥和私钥是否可互换的讨论

公钥加密，私钥解密，公钥和私钥的概念是相对的，公钥加密的内容只能用私钥解密，私钥加密(签名)的内容只能用公钥解密（验签），RSA中的两个密钥数学地位上是一样的，只不过根据需求被定义成了公钥和私钥。

我们知道 RSA 非对称加密的两个密钥分别是(n,e)和(n,d)，当 e 是随机选取的时候，我们将两个密钥中的哪一个定义为私钥其实都是可以的，但是在实际实现 RSA 算法时，本来 e 是随机选取的，但是提前知道用 e 来作为被定义成公钥的那一个密钥时，由于性能考虑一般会把 e 固定选成 65537。这时候公钥和私钥的就不能随便选择了。

有的工具在实现 RSA 算法时，私钥中还会把 p 和 q 都保留下来，或直接把公钥包含在私钥里，这样私钥就能导出公钥。

所以在真正的实现中公钥和私钥是不可以互换的，即加密和签名是“不一样的”。

RSA公钥私钥数学上可互换的推导

Code

公钥和私钥 可以用任意一个加密，然后用另一个解密。

以下为 RSA 算法推导：

取一对互质的数比如 p, q

p = 61

q = 53

n = p * q = 61 * 53 = 3233

欧拉n = (p-1) * (q-1) = 60 * 52 = 3120

求 e：要求 1 < e < 欧拉n  且 e 和 欧拉n 互质； 数有很多，比如17

e = 17

求 d：要求  e * d % 欧拉n = 1

转化公式 x * e + 欧拉n * y = 1 ； 17x + 3120y = 1 ； 算出x = 2753，y = -15

验证要求  17 * 2753 % 3120 = 1

d = 2753

钥匙 A 为： n 和 e

钥匙 B 为： n 和 d


用钥匙 A 加密 123

123^e % n = 123^17 % 3233 = 855

用钥匙 B 解密 855

855^d % n = 855^2753 % 3233 = 123


用钥匙 B 加密 99

99^d % n = 99^2753 % 3233 = 89

用钥匙 A 解密 89

89^e % n = 89^17 % 3233 = 99


【总结】

不知道 p q 的情况下：

钥匙 A 理论上不能 算出 钥匙 B。

钥匙 B 理论上不能 算出 钥匙 A。

e 和 d 哪个标记为公钥，在性能和安全性上貌似有差别，通常 e 被标记为公钥。

大多数工具生成的私钥是包含 p 和 q 的。