使用AES以外的东西有什么吸引力，AES会在各种架构上接收专用的CPU指令来实现它这么有效吗？
#1 楼
我认为，ChaCha20有时比AES更受欢迎的主要原因有三个。在没有专用指令的通用32位（或更高版本）CPU上，ChaCha20通常更快比AES。这样做的原因是
实际上，ChaCha20基于ARX（Addition-Rotation-XOR），是CPU友好指令，而AES使用二进制字段进行Sbox和Mixcolumns计算，它们通常被实现为look
表，以提高效率。 br攻击。 ChaCha20不容易受到此类攻击。 （通过AES-NI实现的AES也不容易受到攻击）。
丹尼尔·J·伯恩斯坦（Daniel J. Bernstein）在宣传算法方面取得了明显高于平均水平的成功。 （我并不是说没有优点，我只是说他的算法在部署方面取得了成功）
当然还有其他原因证明选择AES代替ChaCha20是合理的。
仅举几例：
高端CPU上的专用指令
接收到的密码分析量
侧通道研究的可用性（除了高速缓存定时外） ）保护
评论
$ \ begingroup $
什么是秘密衍生索引？
$ \ endgroup $
– Melab
17年9月9日在4:35
$ \ begingroup $
收件箱。实现8位AES SBox的常见方法是通过查找表。在回合0中，输入/索引是与密钥（机密）异或的纯文本。
$ \ endgroup $
– Ruggero
17年9月9日在8:26
$ \ begingroup $
我使用Nexus 5尝试了多个HTTPS网站，但我认为它们不支持AES-NI。这些网站支持ChaCha20，但在AES之后订购。 Chrome显示它正在通过AES连接。我猜服务器顺序具有更高的优先级？如果大多数服务器指定顺序（出于安全考虑），那么ChaCha20的优势将不会影响许多用例。
$ \ endgroup $
–于富兰
18年7月31日在19:59
$ \ begingroup $
请注意，无需基于查询的S-box，可以有效地实现AES：eprint.iacr.org/2009/129。
$ \ endgroup $
–Pieter Wuille
20-09-07在19:05
$ \ begingroup $
@PieterWuille是的，但仅适用于可并行化模式（如CTR）。它不适用于例如AES-CBC。因此，一般而言，我们在考虑输出大小的情况下在单个加密调用之间进行比较。
$ \ endgroup $
– Ruggero
20-09-08在7:43
#2 楼
除非我们从Google找到信息（例如白皮书和邮件列表帖子），否则我们只能推测为什么选择ChaCha20。我认为高效的软件实施仍然是最可能的原因。 AES-GCM相对较脆，例如在定时攻击方面。可能会另当别论。其他处理器架构正在实现AES加速。例如，便宜的Android手机可能不会包含它。此外，尽管CPU上支持AES-NI，但这并不意味着该软件实际上正在使用该指令。可以使用其他指令加速GCM模式，以加快Galois字段的乘法。可以同时使用AES CTR和Poly1305（同时确保不会以不安全的方式重用密钥） ）。但是随后，组织必须先定义该AEAD算法，然后才能使用它。因此，使用AES可能意味着GCM身份验证，ChaCha20为您提供Poly1305。
评论
$ \ begingroup $
脆是什么意思？
$ \ endgroup $
–JDługosz
16年4月12日在19:07
$ \ begingroup $
我的意思是，尽管就完整算法而言，它是安全的，但当出现任何错误时，它会很快崩溃；随机数重用，小标签大小，定时攻击等。有关更多信息，请参见此处（密钥当然仍受AES保护）。
$ \ endgroup $
–马腾·博德威斯♦
16年4月12日在20:32
$ \ begingroup $
同样值得注意的是，与任何CPU指令集一样，AES-NI是一个黑匣子，没有关于其实现的公开信息。对CPU制造商的不信任是不选择AES的另一个原因。
$ \ endgroup $
– Dreadlockyx
20-2-26在8:19
$ \ begingroup $
@dreadlockyx与硬件RNG不同，我不理解此特殊问题。 AES是一种确定性算法：您可以使用AES-NI加密对象并使用纯软件算法，并验证它们一点一点相同。哎呀，您可以编写一个加密库，随机选择一小部分加密块来验证软件实现。我在这里想念什么？是否担心AES-NI可能会通过侧通道后门泄漏某些东西？
$ \ endgroup $
–丹·伦斯基
20 Mar 20 '20 at 6:11
#3 楼
引用RFC 8439（重点为我）：高级加密标准（AES — [FIPS-197]）已成为加密的黄金标准。其高效的设计，广泛的实现和硬件支持可在许多领域实现高性能。在大多数现代平台上，AES的速度是以前最常用的密码三重数据加密标准（3DES-[SP800-67]）的四到十倍，这不仅使它是最佳选择，但也是唯一的实际选择。
这有几个问题。如果将来
密码分析技术的进步显示出AES的弱点，那么用户将处于一个令人羡慕的位置。由于唯一受其他广泛支持的密码是慢得多的3DES，因此重新配置部署以使用3DES是不可行的。 [Standby-Cipher]描述了这个问题，并且更详细地说明了对备用密码的需求。另一个问题是，虽然AES在专用硬件上的运行速度非常快，但在缺少此类硬件的平台上的性能却要低得多。另一个问题是，许多AES实现容易受到缓存冲突攻击（[Cache-Collisions]）攻击。
因此，“为什么不使用AES以外的任何东西”的问题是老字号“不要将所有鸡蛋都放在同一个篮子里”。然后问题仍然存在，“为什么是ChaCha20，而不是Rabbit，SOSEMANUK或任何其他eSTREAM投资组合密码？” ChaCha20的优点是拥有256位密钥，而eSTREAM产品组合中的其他密码是128位。 HC-128具有类似的HC-256流密码，该密码确实具有256位安全性，可以代替使用。但是，基准测试显示，与ChaCha20相比，它的速度要慢一个数量级。但是，如果128位安全性足以满足您的需求，则在RFC 4503中指定Rabbit，并在一些加密库中实现。 SOSEMANUK和HC-128没有RFC，但是，如果标准允许，则具有可用于实现TLS模式的参考实现。
#4 楼
Daniel J. Bernstein教授是Salsa20及其姐妹流式密码套件（如ChaCha20）的作者。欧盟进行了eSTREAM竞赛和论文共享，DJB领先约一英里。请参阅他的网站https://cr.yp.to/，然后在E.U中有一个竞赛网站。 http://www.ecrypt.eu.org/stream/salsa20p3.html评论
$ \ begingroup $
这本质上是仅链接的答案，在Stack Exchange上对此并不满意。您可以直接在答案中总结标准吗？
$ \ endgroup $
–JDługosz
17年11月18日在3:32
#5 楼
不确定我的速度测试是否可以帮助您了解这个主题。ChaCha20-IETF-Poly1305实际上在2020年（即使自2019年以来）的移动TLS速度测试中实际上比AES-256-GCM慢10％。 AES-256-GCM在2015年时要慢得多，但那时我使用的是低端CPU。
我无法在没有根目录的移动设备上运行SSH，但在台式机上却找不到差异。
我的手机规格QC Snapdragon 845
4个2.8 GHz Kryo 385、4个1.8 GHz Kryo385。
服务器规格，2个服务器，
Intel（R ）Xeon（R）CPU E5-2620 v2 @ 2.10GHz
Intel Core Processor @ 2.4Ghz（Broadwell，没有TSX，IBRS）
我无法在低端手机上进行测试，但是我听说Chacha20 Poly1305在低端CPU上表现更好。
我在Dual Xeon E2670台式机上找不到TLS或SSH的任何差异。
反馈密码的延迟时间比chachas密码的延迟时间长，这是安全性。这也是我的测试结果。
因此，我更喜欢James Yonan的建议。
评论
$ \ begingroup $
我很确定Snapdragon CPU具有AES硬件加速功能，这使其表现出色完全不令人惊讶。
$ \ endgroup $
– SEJPM♦
20年9月7日在8:50
$ \ begingroup $
似乎在使用Armv8加密扩展。它似乎以1 GB / s的速度执行（原始）AES，这使其很有可能被加速。根据维基百科，高通公司从Snapdragon 805起开始实施。实际上，由于独立的SPU似乎也包含AES硬件支持，因此很可能在那里存在多个AES实现。
$ \ endgroup $
–马腾·博德威斯♦
20 Sep 7'9:14
$ \ begingroup $
我认为没有硬件加速的情况下，速度要慢10％才算不错！
$ \ endgroup $
– A. Hersean
20 Sep 7 '14：50
评论
ChaCha在许多没有专用AES指令的CPU上更便宜。我记得Google在说这就是为什么他们在此类设备（许多移动设备）上使用它的原因。加快和加强Android上的Chrome的HTTPS连接-Google安全博客
进行ChaCha：使用加密技术改善移动性能-CloudFlare博客