TLS/SSL性能：密钥长度性能测试

Bertha 。 2023-03-13 05:16 8阅读 0赞

这篇日志总结的是我在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环境中进行测试，并且把测试结果做了统计。

## 对称加密性能 ##

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70][]

命令openssl speed –evp aes-128-gcm

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

![20200511123746581.PNG][]

处理不同的数据块，纵向比较可以看到，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密钥长度下的性能：

![20200511123756786.PNG][]

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

### 不同加密模式比较 ###

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

![20200511123805124.PNG][]

## 公开密钥性能 ##

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 1][]

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

### 数字签名dsa&ecdsa ###

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

![20200511123827365.PNG][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 2][]

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

### Hash算法性能 ###

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

![20200511123845374.PNG][]

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70]: /images/20230312/5e9cbf67a3eb4474bb024b220a191a8a.png
[20200511123746581.PNG]: /images/20230312/cbd0ed95192d496a9f66a0fe24fa0cfc.png
[20200511123756786.PNG]: /images/20230312/3bcc124d2afc47b4a0eb590ec4b3dfde.png
[20200511123805124.PNG]: /images/20230312/dab9e861e61e424fae89f80c37ffc447.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 1]: /images/20230312/21f494f4778347dbbe752e8acd9073b8.png
[20200511123827365.PNG]: /images/20230312/cee41b90deb34518b01d4c35e5b6bd1b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RpbnplbmdUTQ_size_16_color_FFFFFF_t_70 2]: /images/20230312/e3f93e3ffc364c638dff3c699beb08ca.png
[20200511123845374.PNG]: /images/20230312/4cf3d175d9b848579ee729764d9e4068.png