TLS/SSL性能：**长度性能测试

这篇日志总结的是我在Ubuntu下用openssl测试各个密码学算法的性能，从前面的HTTPS抓包里看到，在客户端和服务器端建立完整的TLS握手连接时，Client Hello子消息中带有cipher_suites密码套件列表，Server Hello子消息中含有cipher_suite表示从中选择一个双方都支持的密码套件。随便拿一个密码套件看：

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

密码套件就是一系列密码学算法的组合，例如上面这个密码套件可以看出使用的**协商算法时ECDHE，身份验证算法是ECDSA，**长度为128比特，采用的块密码算法是CBC分组密文连接方式，最后一个HMAC消息验证码算法是SHA256。由此可见，使用了TLS/SSL的HTTPS安全性关键在于密码学算法的组合选择。这些密码学算法通常用来生成**，决定**安全性的因素例如有静态**和动态**，如果使用静态**方式，通常是把**以硬编码的方式保存在数据库中，静态**的问题是一旦泄露了，那么你的信息就面临被**的问题。动态**就是每个TCP传输的**是不同的，即常见的**协商，动态**方式的优点是，协商出来的**只在本次会话中有效，一旦会话结束，连接关闭，那么**也会随之抛弃，待下一次重新建立连接后，再协商出新的会话**，这样即使某一次会话**泄露了，也能保证之前的信息是安全的不会被**，提供了前向安全性。

**长度安全性

决定**安全的还有一个因素是**长度，如果**长度太短，就容易被**，例如不停迭代生成**，把所有可能的**生成尝试一遍。**长度太长也不一定就是好，因为**的用途很多，加密解密，身份验证和消息验证等，加大**长度来提升HTTPS安全性并不是任何情况下都奏效的，结合不同的加密算法，有的**长度较短但安全性更高，如果盲目增大**长度带来的问题很显然就是运算速度会下降很多，造成网络延迟问题。在选择密码套件时，首选安全性高，再考虑性能问题，安全性涉及到数学问题，例如DH**协商算法中需要用到大质数q，以及离散一个很大的数字，因为对于一个大数字，对其做离散是很难得，因此**越长，理论上安全性就越高。在性能方面我们则可以通过测试比较出哪种方法更快，性能更好，网络延迟更小，当然对密码学算法的性能测试，除了本身算法的设计外，还会受硬件参数，例如CPU，操作系统等因素影响，不过在同一环境下测试，也可以大致得出那些算法性能更佳，这篇日志在ubuntu 5.4.0~ubuntu16.04.11操作系统下，gcc版本为5.4.0，openssl版本1.0.2g环境中进行测试，并且把测试结果做了统计。

 

对称加密性能

首先测试对称加密算法的性能，对称加密最简单来说就是加密解密都使用同一个**，同一个算法：

命令openssl speed –evp aes-128-gcm

      由上图可以看到，每隔三秒钟处理一次数据块，数据块的大小依次递增，从16、64、256、1024到8192字节。gcm表示该对称加密采用的块密码方式是counter计数器模式，下面The ‘numbers’ are in 1000s of bytes per second processed展示了每秒钟对于不同大小的数据库，能处理的数据总量，数据块越大，算法的性能就越高。接下来测试下一些常用的对称加密算法，比较一下它们在同一环境下的性能，依次使用speed子命令测试得到的数据统计如下：

处理不同的数据块，纵向比较可以看到，rc4流密码对称加密的性能最好，大概每秒能处理400+MB的数据，如果aes-128-cbc使用了AES-NI指令集进行调优，那么算法的性能直接一跃到最高。

AES-NI指令集

AES对称加密算法由于使用了很多位操作，所以一些高级变成语言在使用其进行加密解密运算时，耗时比较大，使用AES-NI（Advanced Encryption Standard）指令集，即高级加密标准可以优化对称加密密码体制的性能。上面的对称加密测试中，如果不使用AES-NI指令集，命令：

OPENSSL_ia32cap=”~0x200000200000000” openssl speed –evp aes-128-cbc

得到的算法性能是较低的，而使用了AES-NI指令级后，命令：

openssl –speed –evp aes-128-cbc

测得的算法性能提升了四倍左右，可见优化的程度十分明显。

不同**长度比较

上面的测试是对比不同的加密算法，现在在同一加密算法下，不同**长度对性能的影响，拿最常见的aes-128-cbc为例，测试其在128、192和256**长度下的性能：

可以看到，在同一加密算法下，**越长，性能越低，但是安全性理论上来说就越高，所以在选择加密算法时，一定要多加权衡，追求高性能的同时一定不要忽略了安全性，否则得不偿失，通常来说加密算法的安全性也是优先考虑的，其次再到性能。

不同加密模式比较

同一加密算法下，不同的**长度对性能有影响，此外，不同的加密模式也会影响算法的性能，例如使用的是流密码方式还是块密码方式，同样测试对称加密算法下，使用cbc密文分组连接模式和GCM计数器模式的性能如下：

 

公开**性能

公开**方式的测试标准和对称加密测试标准不同，对称加密由于是使用一个算法和**进行加密和解密，所以测试时标准时每秒钟加密解密的数据大小，公开**方式分为公钥和私钥，私钥用来加密，公钥用来解密，所以测试的标准就变为了每秒钟运算的次数。例如我们测试rsa算法的性能：

公开**算法在生成公钥时耗时比生成私钥时慢那么一点，原因前面可以看到公钥的数据量要比私钥大很多。在数字签名方面，生成签名的速度要比校验的速度慢很多很多，同样的，**长度越长，算法的性能就越低，这个很容易理解。

数字签名dsa&ecdsa

上面rsa算法可以用来数字签名，还有两种dsa和ecdsa的性能也测试下，在测试前我们大致能知道谁的运算速度更快，rsa无论是加密解密，生成签名和验证签名，都是并不复杂的取余运算。dsa则比较复杂，计算步骤也比rsa多，性能应该会比rsa差：

和rsa对比，dsa无论在每秒生成签名次数和校验签名次数都比rsa低。Ecdsa测试结果如下：

不过这个ecdsa的测试结果和我的预期不太一样- -、测了很多次性能都不佳，所以这里我要再强调一遍！这篇日志测试仅供参考！在不同的操作系统，GCC版本，CPU等因素下，测试结果可能相差很大，例如上面支持AES-NI指令集的aes算法提升是非常大的，即使用CBC块密码方式也比流密码方式的rc4快很多。不过这里所有测试我都在同一环境下，结果经供参考。

Hash算法性能

最后测试的是各种Hash算法的性能，Hash算法比较常见的用途是在身份校验方面，用来计算摘要值，有sha1、sha256、sha384、sha512和md5等：

从测试结果来看，不同的分组（数据库）长度，分组越大，性能也是越高，在sha1、sha256、sha384和sha512之间比较，哈希值越长，性能越低，和前面的加密解密算法类似，**长度越长，性能就越差，当然不能忽视安全性理论上来说越高这一点。