carloscn/blog

3.0_Security_对称密钥算法加解密

carloscn opened this issue · 0 comments

carloscn commented

3.0_Security_对称密钥算法加解密

定义：对称加密算法即，加密和解密使用相同密钥的算法。（加密Key=解密key）；对称密钥算法又分为分组密码 (Block Cipher)和流密码(Stream Cipher)，在算法模式上，分为ECB/CBC/CFB/OFB/CTR这些模式。

常用算法包括DES(Data Encryption Standard，数据加密算法) 、3DES(Triple Data Encryption Algorithm，三重数据加密算法)、 AES(Advanced Encryption Standard，高级加密标准，又称Rijndael加密法) 、PBE(Password-based encryption，基于密码验证)、RC4（来自Rivest Cipher 4的缩写）、 SM1 、SM4（国产）。

ChaCha20-Poly1305是Google所采用的一种新式加密算法，性能强大，在CPU为精简指令集的ARM平台上尤为显著（ARM v8前效果较明显），在同等配置的手机中表现是AES的4倍（ARM v8之后加入了AES指令，所以在这些平台上的设备，AES方式反而比chacha20-Poly1305方式更快，性能更好），可减少加密解密所产生的数据量进而可以改善用户体验，减少等待时间，节省电池寿命等。

除此之外，还有3GPP下面适用于基站的加密算法，包括KASUMI/ZUC/SNOW-3G。由此可见，对称加密主算法种类繁多。一般的，描述对称加密算法， 主算法 + 模式，例如AES256 使用ECB模式。

本节讲述对于对称加密算法的一些共性的知识：

  • 对称加密的应用场景(+对称加密的密钥存储讨论)
  • 对称加密的流加密和块加密
  • 对称加密的算法模式

1. 应用场景

由于算法效率较高，一般用于对效率有要求的实时数据加密通信。比如在使用 VPN 或者代理进行加密通信时，既要保证数据的保密性，又要保证不能有高的延迟，所以通常会使用对称加密算法。还有我们常用的WinZIP和WinRAR对压缩包的加密和解密。

对称密钥问题

既然接受和发送方使用相同的密钥，那么这里就存在：

  • 密钥协定和发布的安全问题；
  • 在1个Server和N个Client之间要使用加密通信，导致密钥不平衡问题：
    • 如果一套密钥，密钥安全性大打折扣，等同没有加密；
    • 如果每一个通信都要一套密钥，Server要管理N个密钥，通信成本问题；

因此在对称加密中比较棘手的问题就是密钥管理的问题，通常我们使用非对称加密传输密钥，在某些场景为了增强安全性，还会使用key blob的方式。如图所示，为NXP-AN12838设计的key blob多重AES计算出最终的密钥1：

2. 块加密和流加密2

无论是流加密还是块加密，本质都是把明文转换成密文，仅仅是输入和输出的形式不太一样，当然他们有着不同的优缺点，因此将其应用于不同场景，发挥其最大的优势，避免劣势。

2.1 块加密

如图所示，为一个块加密的其中一种示例：

块密码算法也叫分组密码算法，从字面意思就可以知道，它把加密和解密序列分成了一个个分组，最后把每一块序列合并到一起，形成明文或者密文。根据不同的分组加密方式（算法模式），每个分组之间可以有联系，也可以没有联系。算法模式如下：

  • Electronic Code Book (ECB) Mode
  • Cipher Block Chaining (CBC) Mode
  • Cipher Feedback (CFB) Mode
  • Output Feedback (OFB) Mode
  • Counter (CTR) Mode
  • XEX-based tweaked-codebook mode with ciphertext stealing (XTS)
Mode Min Formulas Ciphertext
Electronic codebook (ECB) Yi = F(PlainTexti, Key) Yi
Cipher block chaining (CBC) Yi = PlainTexti XOR Ciphertexti−1 F(Y, Key); Ciphertext0 = IV
Propagating CBC (PCBC) Yi = PlainTexti XOR (Ciphertexti−1 XOR PlainTexti−1) F(Y, Key); Ciphertext0 = IV
Cipher feedback (CFB) Yi = Ciphertexti−1 Plaintext XOR F(Y, Key); Ciphertext0 = IV
Output feedback (OFB) Yi = F(Yi−1, Key); Y0 = F(IV, Key) Plaintext XOR Yi
Counter (CTR) Yi = F(IV + g(i), Key); IV = token() Plaintext XOR Yi

带消息验证的：

  • Galois/counter (GCM)
  • Counter with cipher block chaining message authentication code (CCM)
  • Synthetic initialization vector (SIV)
  • AES-GCM-SIV

最早的时候ECB/CBC/CFB/OFB是在1981年定义的DES手册中出现，参考 FIPS 81 手册。2001年，NIST修订AES块加密，并且在此次修订中增加了CTR模式，可以参考SP800-38A ，并且NIST把CTR作为推荐 Recommendation for Block Cipher Modes of Operation 。在2010年，NIST把XTS-AES加入到 SP800-38E 标准中，并作为_Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices_.

加密模式ECB/CBC/CFB/OFB/CTR/XTS提供了保密特性，但是对于意外修改(accidental modification)和恶意篡改(malicious tampering)，这几个模式并没有很好的抵抗能力。针对意外修改和恶意篡改NIST增加了消息认证码message authentication code，例如： CBC-MAC, 或者是数字签名digital signature.

  • 在2002年，HMAC(Keyed-Hash Message Authentication Code)被批准，参考FIPS 198
  • 在2005年，CMAC(Cipher-based Message Authentication Code)被定义，参考SP800-38B
  • 在2007年，GMAC(Galois Message Authentication Code)被正式发布，参考 SP800-38D

密码学界观察到，将保密模式与真实性模式合成（组合）可能很困难并且容易出错。因此，他们开始提供将机密性和数据完整性结合到单个密码原语（加密算法）中的模式，密文+tag形式。这些组合模式称为authenticated encryption，简写AE(Authenticated encryption with additional data (AEAD) modes)。AE的模式为：CCM (SP800-38C), GCM (SP800-38D), CWC, EAX, IAPM, and OCB.

2.1.1 ECB模式

ECB模式是最简单的加密模式，就是把明文信息按照块大小分组，然后对块加密/解密，最后拼装在一起，块和块之间没有任何联系和依赖。ECB模式要求待处理的数据长度为16的倍数，当数据长度不满足要求时则先进行填充操作。填充有很多方式，比如ISO 7816-4，这个是智能卡的标准；还有PKCS5，ANSI_X923等等。

ECB (Electronic codebook)
Encryption parallelizable Yes
Decryption parallelizable Yes
Random read access Yes

ECB由于这种简单的结构缺乏diffusion，ECB已经不被推荐使用了。

麦克劳·香农 引入了混淆（confusion）和扩散（diffusion）的概念，在计算机加密算法中非常重要。
Confusion是为了保证密文中不会有明文的线索，防止密码分析员从密文中找到模式，从而求出对应的明文（一般使用替换技术制造混淆）
Diffusion是增加明文的冗余度，使其分布在行和列中。（一般通过块内置换技术）

这里有一个非常有趣的实验，可以作为参考，使用ECB模式对一张位图进行加密，加密之后依然能看到图像的一些轮廓信息：

ECB模式还可以使没有完整性保护的协议更容易受到重放攻击replay attacks，因为每个块都以完全相同的方式解密。黑客可能解密其中几个块之后利用这几块不断进行攻击。

2.1.2 CBC模式

Ehrsam, Meyer, Smith and Tuchman在1976年发明了cipher block chaining (CBC) [23]。 在CBC模式中，每一个明文块和前一个密文块是有关联的（这种依赖性可以抵抗防重放攻击），他们使用 XORed进行位运算。这样的话每个密文块都依赖于运算到此处为止所处理的所有明文块（扩散性）。为了使每条消息唯一，必须在第一个块中使用初始化向量。（IV作为第一个密文块的替代，可以理解，凡是密文和明文操作都需要IV作为第一个密文块的替代），解密也需要同样的IV。

Cipher block chaining(CBC)
Encryption parallelizable No
Decryption parallelizable Yes
Random read access Yes

CBC加密过程如下：

CBC解密过程如下：

我们可以通过一个简单的例子来看一下CBC如何加密和解密：

加密 解密

我们可以注意特性，明文00和01最终加密出来的结果都是11，说明明文和密文并非ECB一样线性映射的，这样就可以抵抗重放攻击。

从加密的流程来看，CBC加密的是顺序化的（下一次加密需要依赖上一次的结果），因此不能并行化。而且需要和IV进行XORed操作，所以明文长度必须是IV的整数倍，如果明文不是IV的整数倍则需要进行填充（这就导致了一种密文窃取的可能性，参考文献3的5. CBC填充攻击）。

明文或IV中的1位变化，就会影响整个加密的结果。而使用不正确的IV解密的话，只会导致第一个明文块损坏，后续的明文都是正确的。这是因为每个块都与前一块的密文而不是明文进行异或运算，所以在将前一块用作当前块的IV解密之前，不需要对其进行解密。这意味着可以从两个相邻的密文块中恢复明文块，所以解密过程可以并行化。对密文的一位更改会导致相应的明文块完全损坏，并反转下一个明文块中的相应位，但其余块保持不变。

上面我们可以利用解密特性来使用CBC：Explicit initialization vectors 参考："The Transport Layer Security (TLS) Protocol Version 1.1"，通过在明文之前加一个随机块（不关心这个块），加密按照正常方式进行，解密的时候可以使用随机的IV进行解密，因为只有第一个块被破坏，而这个块是我们不关心的，可以被丢弃，其余的解密块就是原始明文。

针对于CBC使用错误的IV只有第一个明文块被破坏的问题，提出了PCBC的模式扩展方案。其作用就是，在解密过程中如果IV使用错误，则所有解密的明文全部被破坏。在结构上，相比于CBC在密文块给下一个密文之前，把明文和密文再做一次XORed。因此PCBC，加解密都无法实现并行。参考："Kryptographie FAQ: Frage 84: What are the Counter and PCBC Modes?". 

2.1.3 CFB

不是所有的应用场景都需要处理数据块，而面对于面向字符的应用程序，也需要进行加密。例如，在终端输入字符的时候，要是用安全传输，此时可以使用流加密的方法，也可以使用块加密的方式，那么块加密的方法CFB就是一个很好的选择。因为在CFB模式中，数据能够用更小的单元进行加密（可以小到1bit，也可以大到128bit）。而通常意义的块加密大都是以64bits为一个块。

密码反馈（CFB）模式以其最简单的形式使用分组密码的整个输出。在这种变体中，它与CBC非常相似，将分组密码转换为自同步流密码。此变体中的CFB解密几乎与反向执行的CBC加密。从结构上来看，CBC使用当前明文 XOR 上一个密文块 [enc_func] key，而CFB是上一个密文块 [enc_func] key XOR 当前明文，区别仅仅是顺序做了调整，因此和CBC的性质一致：

Cipher feedback(CFB)
Encryption parallelizable No
Decryption parallelizable Yes
Random read access Yes

CFB加密过程如下：

CFB解密过程如下：

CFB-1, CFB-8, CFB-64, CFB-128, etc.

NIST SP800-38A定义了具有比特宽度的CFB，参考："SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques"。CFB模式还需要一个整数参数，表示为s，例如1≤ s≤ b、 在以下CFB模式的规范中，每个明文段（Pj）和密文段（Cj）由s位组成。s的值有时会包含在模式名称中，例如，1位CFB模式、8位CFB方式、64位CFB或128位CFB。这些模式将截断底层分组密码的输出。

CFB与CBC模式一样，明文中的更改在所有的密文块都受到影响，因此加密无法并行化。而解密也可以并行化。与CBC模式相比，CFB、OFB和CTR有两个优点：块密码只用于加密方向，消息不需要填充到密码块大小的倍数。

2.1.4 OFB

输出反馈（OFB）的结构与CFB有些相似，同样可以模拟流密码。但OFB使用加密函数的输出作为下一轮算法输入，所以其加解密过程都不可以并行运算，而CFB的解密过程可以并行。

OFB极其适合在易出现噪音的信道中传输数据，其bit错误不会发生扩散，仅仅影响对应的一个bit位。在传输数字信号，音视频这种单比特错误容忍度较高或者以纠错码编码过的数据简直无敌。但是要注意OFB的IV必需是一个时变值，因为OFB的加密输出完全不依赖明文，仅仅与IV和KEY相关。假如IV和KEY都是固定值，等同于与明文进行异或的输出就是固定的，一旦这些输出被攻击者碰撞出来，通过简单的异或操作就能将密文还原成明文4。对于ECCerror-correcting codes 有一定的容忍性。

另一个问题是OFB抵抗消息流篡改能力很弱，因为其bit错误不会扩散，那么攻击者完全可以在密文中修改bit值并且更新校验码，从而使改动不被纠错码发现，破坏了信息安全的不可篡改性。

Output feedback(OFB)
Encryption parallelizable No
Decryption parallelizable Yes
Random read access Yes

OFB的加密过程：

OFB的解密过程：

每个输出反馈块密码操作都依赖于所有先前的操作，因此不能并行执行。但是，由于明文或密文仅用于最终的XOR，因此可以提前执行分组密码操作，一旦明文或密码可用，就可以并行执行最后一步。

通过使用具有恒定零串的CBC模式作为输入，可以获得OFB模式密钥流。这可能很有用，因为它允许使用CBC模式的快速硬件实现来进行OFB模式加密。

2.1.5 CTR

与OFB一样，计数器模式将块密码转换为流密码。它通过加密“计数器”的连续值来生成下一个密钥流块。计数器可以是任何产生序列的函数，该序列保证不会长时间重复，尽管实际递增一个计数器是最简单和最流行的方式。简单确定性输入函数的使用曾经是有争议的；批评者认为，“故意将密码系统暴露于已知的系统输入是不必要的风险”。然而，如今CTR模式被广泛接受，任何问题都被认为是底层分组密码的弱点，无论其输入是否存在系统性偏差，该密码都是安全的。与CBC一起，CTR模式是Niels Ferguson和Bruce Schneier推荐的两种分组密码模式之一。

CTR模式由Whitfield Diffie和Martin Hellman于1979年引入。CTR模式具有与OFB相似的特性，但也允许在解密期间进行随机访问。CTR模式非常适合于在多处理器机器上运行，其中可以并行加密块。此外，它不会受到影响OFB的短周期问题的影响。

Counter(CTR)
Encryption parallelizable Yes
Decryption parallelizable Yes
Random read access Yes

如果IV是随机的，则可以使用任何可逆运算（级联、加法或XOR）将它们与计数器组合，以产生用于加密的实际唯一计数器块。在非随机随机数（如数据包计数器）的情况下，随机数和计数器应级联（例如，将随机数存储在128位计数器块的高位64位中，将计数器存储在低位64位中）。在许多情况下，简单地将nonce和counter添加或异或为单个值会破坏所选明文攻击的安全性，因为攻击者可能能够操纵整个IV–counter对以导致冲突。一旦攻击者控制了IV计数器对和明文，将密文与已知明文进行异或将产生一个值，当与共享相同IV计数器对的另一个块的密文异或时，将解密该块。

请注意，此图中的nonce相当于其他图中的初始化向量（IV）。但是，如果偏移量/位置信息已损坏，则由于依赖于字节偏移量，将无法部分恢复此类数据。

CTR的加密过程：

CTR的解密过程：

NIST的附录B中重点讨论了CTR模式的counter block生成准则，有以下两点：1. 组成input值的counter需要由递增函数生成以保证每个counter block不会重复；2. 需要选择一个合适的初始值来保证后续参与到消息分组运算的counters（各组input block）都是唯一的。同时，NIST仅仅是建议了一种安全使用CTR模式的方式，并没有规范counters生成的标准算法。其中一种可以表达为8 bytes nonce + 8 bytes counter。

如nonce值为:
9e b7 6f ac 45 af 8e 51 30 c8 1c 46 a3 5c e4 11  

第一组input组成方式为 nonce|counter:
9e b7 6f ac 45 af 8e 51 00 00 00 00 00 00 00 00

接下来则分别是:
9e b7 6f ac 45 af 8e 51 00 00 00 00 00 00 00 01  
9e b7 6f ac 45 af 8e 51 00 00 00 00 00 00 00 02  
9e b7 6f ac 45 af 8e 51 00 00 00 00 00 00 00 03  
...  
9e b7 6f ac 45 af 8e 51 ff ff ff ff ff ff ff ff

对于一段消息message，counters需要唯一，所以消息的分组个数不能超过264即消息总大小不超过264x16 bytes，这已经是一个很恐怖的数据量了。就算把counter占位减半，使用12字节nonce和4字节counter，能够处理的消息总大小也达到了64G。

2.1.6 XTS5

XTS即基于XEX(XOR-ENCRYPT-XOR)的密文窃取算法的可调整的密码本模式（Tweakable Codebook mode），该算法主要用于以数据单元（包括扇区、逻辑磁盘块等）为基础结构的存储设备中静止状态数据的加密。

我们都知道磁盘上的数据是有一定格式的，比如一个扇区是512字节，磁盘加密直接要对写入扇区的明文进行加密，记录在磁盘扇区上的是相应的密文。而我们通过传统的AES加密方法，比如CBC加密模式，密文须包含一个128bit的初始向量。那么问题来了，我们岂不是要腾出额外的128个bit专门存储初始向量？这样做是增加了磁盘的开销，而且明文和密文在扇区上的存储也不是一一对应的，这给磁盘底层的加密实现带来很大的麻烦。更为关键的是，传统的加密算法，更改密匙非常不便，一旦更改，就意味着要重新进行密匙扩展算法，对磁盘来说要增加很大的开销，同时还要担心密匙泄露的问题。

在这种情况下，针对磁盘加密的特点，2002年，Moses Liskov，Ronald L.Rivest, David Wagner,首次提出了可调整的分组密码这个概念，跟传统的分组密码相比，除了密匙和明文这两个输入外，还引入另外一个输入---tweak，即可调整值。这样做的好处是，在不更改密匙的情况下，仅仅改变tweak值，就可以给加密系统提供多变性，既减少了磁盘的开销，也不怕密匙泄露，因为tweak值是公开的，就算泄露了tweak值，如果不知道密匙，是无法破解系统的。而且，这种算法，不需要初始向量，也就避免我们上面所述的明文和密文在扇区上的存储不对应的问题。

简单介绍下其原理，以传输单个128bit数据块为例：

i为128-bit调整值，j为128-bit数据块在数据单元中的位置值,C为128-bit密文数据块。AES-enc为标准AES算法，key2为调整值密匙，key1为数据密匙，模乘操作中 α为GF(2^128)域中对应于多项式x的本源。

计算的步骤顺序如下：

  • T <---- AES-enc(key2,i) ⓧ (α^j );
  • PP <----P⊕T
  • CC<---AES-enc(Key1,PP)
  • C<--CC⊕T

需要指出的是，j代表数据块在数据单元里的index，比如256个bit数据块，那么 0bit-127bit的j=1，128bit-256bit 的j=2。j 的引入，是让各个数据块的加密保持独立。

openssl 的xts 的示例： https://gist.github.com/ants/862cb941057bdb8db00c72711d2b826c#file-ssl-encrypt-c

2.1.7 总结一下

对于上述五种模式，可以总结为：

2.2 流加密

在密码学中，流密码（英语：Stream cipher），又译为流加密、资料流加密，是一种对称加密算法，加密和解密双方使用相同伪随机加密数据流（pseudo-random stream）作为密钥，明文数据每次与密钥数据流顺次对应加密，得到密文数据流。实践中数据通常是一个位（bit）并用异或（xor）操作加密。

该算法解决了对称加密完善保密性（perfect secrecy）的实际操作困难。“完善保密性”由克劳德·香农于1949年提出。由于完善保密性要求密钥长度不短于明文长度，故而实际操作存在困难，改由较短数据流通过特定算法得到密钥流。

2.2.1 基本原理

流密码算法，或者叫序列密码，算法大概的原理是，每次加密都通过密钥生成一个密钥流，解密也是使用同一个密钥流，明文与同样长度的密钥流进行异或运算得到密文，密文与同样的密钥流进行异或运算得到明文。密钥流的产生可以来源于一次性密码本或者线性同余生成器。

伪随机密钥流（keystream）由一个随机的种子（seed）通过算法称为：PRG，pseudo-random generator）得到，k作为种子，则G（k）作为实际使用的密钥进行加密解密工作。

为了保证流加密的安全性，PRG必须是不可预测的。弱算法包括glibc random()函数，线性同余生成器（linear congruential generator）等。

一次性密码本

一次性密码本（英语：one-time pad，缩写为OTP）是古典密码学中的一种加密算法。是以随机的密钥（key）组成明文，且只使用一次。

流密码算法是以“一次性密码本“One Time Pad为雏形演变出来的加密算法，一次性密码本算法很重要的一个特性就是密钥使用的”一次性“，来看看一次性密码本的算法原理。

一次性密码本即Vernam Cipher，是由Gilbert Vernam在1917年，开发的一种加密算法。一次性密码本的操作核心是异或运算，明文和同样长度的密钥进行异或运算，得到密文，密文根据加密时使用的的密钥进行异或运算，解密得到明文。举个例子，

假如我们的明文是：
00100110 11110110 11110110 11100110

使用的加密密钥是：
10011110 10100110 11010110 11001110

那么明文与密钥进行加密异或运算，得到的密文就是：
10111000 01010000 00100000 00101000

之后密文通过同样的密钥进行异或运算，即可解密出明文：
10111000 01010000 00100000 00101000
10011110 10100110 11010110 11001110
00100110 11110110 11110110 11100110

这就是一次性密码本的原理，一次性密码本保证安全性的方法是，每一次加密解密后，下一次加密解密会更换不同的密钥，也就是每次都更换密钥。对于同一个明文信息，每一次加密都会使用不同的密钥，这样即使别人掌握了其中一个密钥和密文，他也无法确定这个密文是否是通过这个密钥加密生成的，无法确定该密文使用这个密钥解密出的就是原始明文。

线性同余生成器

线性同余生成器中，令r[0]为seed，r[i] =（a * r[i-1] + b）mod p，其中a，b，p均为常数，则可轻易顺次推出整个密钥流，从而进行解密。

2.2.2 流密码的实例

WEP

一个失败的例子即WEP网络传输协议。

  • 该协议中服务器和客户端共享同一密钥流，该密钥流由一段24位的数据IV和一段密钥组成，表示为PRG（IV || k），通过异或操作对明文数据流加密。而IV最多组合情况为224个（约16M大小），因而攻击者可轻易暴力破解获取IV，或通过多次截取数据包（当数据流量足够大，密钥流必定多次重复）最终得到明文。
  • 另一个弱点在于，802.11网卡重启后自动设置IV为初始状态0。两种情况下都能表明WEP安全性并不尽如人意。

WEP已被WPA和WPA2取代。 WPA是WEP增强版底层算法使用RC5流密码，而WPA2底层是AES块密码。

硬盘加密

当硬盘使用流加密时，同样会使用同一密码本对不同文本进行加密，因而调换两个文本中少量信息，可以得到同样的冗余结果。避免这个问题的方案通常是避免使用流加密。

RC4

在密码学中，RC4（来自Rivest Cipher 4的缩写）是一种串流加密法，密钥长度可变。它加解密使用相同的密钥，因此也属于对称加密算法。RC4是有线等效加密（WEP）中采用的加密算法，也曾经是TLS可采用的算法之一。

由美国密码学家罗纳德·李维斯特（Ronald Rivest）在1987年设计的。由于RC4算法存在弱点，2015年2月所发布的 RFC 7465 规定禁止在TLS中使用RC4加密算法[1]。

RC4由伪随机数生成器和异或运算组成。RC4的密钥长度可变，范围是[1,255]。RC4一个字节一个字节地加解密。给定一个密钥，伪随机数生成器接受密钥并产生一个S盒。S盒用来加密数据，而且在加密过程中S盒会变化。

由于异或运算的对合性，RC4加密解密使用同一套算法。

Salsa20/Chacha20

Salsa20是一种流加密算法，由丹尼尔·J·伯恩斯坦提交到eSTREAM。它创建在基于add-rotate-xor（ARX）操作的伪随机函数之上——32位模加、异或（XOR）和循环移位操作。Salsa20映射一个256位密钥、一个64位nonce以及一个64位流位置到一个512位的输出（也存在一个128位密钥的版本）。这使Salsa20具有了不同寻常的优势，用户可以在恒定时间内寻求输出流中的任何位置。它可以在现代x86处理器中提供约每4–14次循环周期一字节的速度，并具有合理的硬件性能。它没有注册专利，并且Bernstein还撰写了几篇对常见架构优化的公有领域实现。

一个相关的密码算法ChaCha，具有类似的特点，但有不同的循环移位函数，已在2008年由伯恩斯坦发布。

Google选择了伯恩斯坦设计的，带Poly1305消息认证码的ChaCha20（即ChaCha20-Poly1305），作为OpenSSL中RC4的替代品，用以完成互联网的安全通信。Google最初实现了HTTPS (TLS/SSL)流量在Chrome浏览器与Google网站之间的通信。

Change Log

[1] : 增加 2.1.6 XTS mode

Ref

Footnotes

  1. NXP - AN12838 - Strengthening Public Key Cryptography using CAAM Secure Key ↩

  2. Difference Between Block Cipher and Stream Cipher ↩

  3. 对 CBC 模式的一些攻击 ↩

  4. 分组密码算法工作模式 ↩

  5. XTS-AES模式主要是解决什么问题，是怎样解决的? - 蒋伟伟的回答 - 知乎 ↩