Skip to content

Instantly share code, notes, and snippets.

@byronhe

byronhe/modern_crypto.md

Last active March 28, 2022 07:51
Show Gist options
  • Save byronhe/232d22f1d3dcaa0a20cb to your computer and use it in GitHub Desktop.
Save byronhe/232d22f1d3dcaa0a20cb to your computer and use it in GitHub Desktop.
Download ZIP
现代密码学实践指南[2015年]
Raw
modern_crypto.md

现代密码学实践指南[2015年]

标签（空格分隔）： 密码学

本文介绍目前现代密码学的最先进技术， 前半部分主要翻译自 《Cryptographic Right Answers》，附上收集的资料，和byron个人的理解。

密码学理论艰深，概念繁多，本人知识水平有限，错误难免，如果您发现错误，请务必指出，非常感谢!

###下文分类介绍在各种适用场景下，你应该使用的现代密码学算法

###1. 加密数据 : 按照优先级，应该选择: (1) 首选 NaCl库，或者libsodium库，使用里面的crypto_secretbox()/crypto_secretbox_open() 函数 (2) Chacha20-Poly1305 算法 (3) AES-GCM 算法

适用场景:当你需要避免把明文数据在网络上传输的时候。

以上3种算法，都是AEAD类的算法，AEAD是2015年最好的选择。 其中的(2)和(3)在结构上类似：一个流加密模式的算法，配合一个多项式结构的MAC。 (2)是一个流加密算法，配合一个为通用cpu优化的MAC算法， 对密码学库的实现者来说，Poly1305也比GCM更容易安全地实现。 AES-GCM是工业标准(TLS目前主要用的就是AES-GCM)，现代CPU通常都有专门为AES-GCM设计的硬件指令，但是在没有硬件指令支持的CPU上(比如32位的arm)，(3)性能低于(2)。

此外，应该

  • 避免AES-CBC
  • 避免AES-CTR
  • 避免64bit块大小的块加密算法--(说的就是你--BlowFish)
  • 避免OFB模式
  • 不要使用RC4，RC4已经被攻破

###2. 对称密钥长度 : 选择使用256bit长度的密钥

适用场景：只要你在使用密码学，你就应该注意对称密钥长度

请记住：不要把对称加密（如AES）的key长度，和非对称加密(如RSA)的key长度搞混淆了，对称加密的key通常比非对称加密的key短多了。

下表对比了相同安全程度时，不同算法的密钥长度，单位:bit

Symmetric ECC DH/DSA/RSA
80 163 1024
112 233 2048
128 283 3072
192 409 7680
256 571 15360

此外，应该

  • 避免使用巨大key的算法(使用远大于256的key，只能说明使用者没有安全概念)
  • 避免把多个加密算法串联叠加起来使用，这并没有什么卵用
  • 避免128bit以下的key长度(比如，哥们求你别再提DES这种56bit密钥的古董了)

###3. 对称签名: 应该选择 HMAC 类的算法

适用场景：安全加固一个API，如各种开放API的调用方认证

如果对一个API，你需要做认证(authenticating)，但是不需要做加密(encrypting)，记得千万不要自己发明算法，你自己发明的MAC算法基本都有安全漏洞，如果不信，请Google一下 "长度扩展攻击" 长度扩展攻击 Flickr的漏洞案例

同时，必须要注意的是，要使用一个常数时间字符串对比算法（这个地方和码农的常识完全相反，请务必留意）

此外，应该

  • 避免自行设计的“带密码的hash”结构，你的设计基本都是有安全漏洞的
  • 避免HMAC-MD5，避免HMAC-SHA1，使用HMAC-SHA256, HMAC-SHA512等
  • 避免复杂的多项式MAC
  • 避免加密hash值的结构
  • 避免CRC

###4. Hashing/HMAC 算法 应该选择SHA2类的算法:: SHA-256, SHA-384, SHA-512, SHA-512/256

优先使用 SHA-512/256，SHA-512/256这个算法把 SHA-512 的512bit输出截短到256bit，避开了length extension 攻击。 同时，目前SHA-2是很安全可靠的，你不需要升级到SHA-3.

此外，应该

  • 避免SHA-1
  • 避免MD5
  • 避免MD6

###5. 随机ID 应该使用256 bit的随机值

一定要使用 /dev/urandom，请认准这个

此外，应该

  • 避免用户空间的随机数生成器如:havaged,prngs,egd,等
  • 避免/dev/random

###6. 密码处理 按照优先级顺序,选择：

  • scrypt
  • bcrypt
  • 如果以上2个都没有，那就用PBKDF2

此外，应该

  • 避免直接SHA-2
  • 避免直接SHA-1
  • 避免直接MD5

###7. 非对称加密 应该使用NaCl库

适用场景：当你需要加密消息，发给陌生人，并且对方异步接收消息，做离线解密时。这是一个很窄的应用案例，这种用法有个名字叫电子信封(digital envelope)，典型比如gpg加密文件后发送。

这条是几条之中最难做正确的，不要使用底层的密码学库，比如OpenSSL或者BouncyCastle。

你应该停止使用RSA，并且切换到椭圆曲线类体制，原因是：

  • 对RSA的攻击能力的进步 --- 定义在传统质数域上的乘法运算(应用包括DH,DSA,ElGamal等)，要比椭圆曲线域上的乘法运算快得多。这是由于质数域上数域筛法（number field sieve,NFS）的进展，而在椭圆曲线域上，没有NFS这类算法。
  • RSA (和DH) 或迫使你考虑“向后兼容性”，而椭圆曲线体制没有这种兼容性包袱。TLS最近的几个安全漏洞，部分原因也是由于这种向后兼容性，导致已经被破解的陈旧算法存在
  • RSA在一般场景中，都是直接用公钥做非对称加密，这种用法丧失了前向安全性(Perfect Forward Secrecy)。而椭圆曲线就不提倡，也很难这样使用，这样你就不会害死自己了。
  • 在椭圆曲线体制下，保证正确性和安全性的重任，主要由密码学家承担，密码学家会提供一组曲线参数，在某一性能水平下，针对安全性和性能做优化。这样程序员不容易误用而害死自己。在RSA体制下，正好相反，程序员必须提供参数来保证正确性和安全性，就算是RSA-OAEP这种很好的设计，程序员也必须知道怎么提供参数，这样程序员很容易搞错。

如果你必须使用RSA，一定要使用RSA-OAEP with SHA256，指数使用 65537

  • 避免 RSA-PKCS1v15
  • 避免 ElGamal
  • 避免 RSA

###8. 非对称签名 应该使用NaCl，Ed25519，或者RFC6979

应用场景：如果你在设计一种新的比特币，或者一个给Ruby Gems或者Vagrant imges文件签名的系统，或者数字版权保护系统(DRM)，其中一系列的文件需要离线做认证； 或者你在设计一个加密消息传输层

上一条的内容在此处全部适用。

在10+年做付费软件安全评估的工作经历中，我只有屈指可数的几次，遇到使用RSA-PSS的用户，RSA-PSS是一个学术界的推荐算法。

过去10年，非对称签名最主要的应用场景是比特币，和前向安全的密钥协商（TLS协议里面的ECDHE）。 其中最主要的算法全都是基于椭圆曲线体制的。务必警惕新出现的使用RSA签名的系统，很有可能有问题。

在过去几年中，业界有一种趋势：放弃传统DSA签名，改为难以误用的确定性签名体制，其中的EdDSA(不要和ECDSA搞混了喂！)和RFC6979是最好的例子。这种趋势的主要是受到2010年索尼PlayStation 3的 ECDSA私钥被破解事件的影响，在这个案例中，索尼公司的码农错误地把一个随机数重复使用来做ECDSA签名，形成了漏洞，使得破解者据此直接把私钥算出来了。确定性签名体制在设计中不再依赖随机数生成器，因此彻底避开此类误用。所以你应该优先使用确定性签名体制。

  • 避免RSA-PKCS1v15，避免RSA，避免ECDSA，避免DSA
  • 特别要避免常规的DSA和ECDSA

###9. Diffie-Hellman 密钥交换 应该使用NaCl，Curve25519，或者DH-2048

适用场景:如果你在设计加密消息传输系统，并且无法使用固定对称密码

这是很棘手的一条，主要考量如下：

  • 如果你能使用NaCl库，那就使用NaCl库。你甚至不需要管NaCl是什么。
  • 如果你能使用一个可信赖的第三方库，那就使用Curve25519，这是一条现代的ECDH曲线，有丰富的开源代码，性能经过高度优化，被彻底地安全分析过。并且Curve25519即将进入TLS 1.3版本标准。
  • 但是绝对不要自己实现Curve25519，也绝对不要自己移植Curve25519的C代码
  • 如果你不能使用第三方ECDH库，但是可以使用DH库，那就使用DH-2048，使用1个标准的2048 bit的群。
  • 但是不要使用传统的DH，如果你需要协商DH参数，或者和其他实现互操作
  • 如果你一定要做握手协商，或者和旧软件互操作，那么考虑使用NIST P-256, NIST P-256 有广泛的软件支持。
  • 写死在代码里的DH-2048参数，比NIST P-256更安全。NIST P-256比协商出来的DH更安全。
  • 但是，由于NIST P-256的实现有一些陷阱，所以一定要谨慎选择可信赖的，广泛使用使的第三方库
  • P-256 可能是NIST曲线中最安全的，不要使用P-224。

DH（密钥协商）算法确实很难用，但是它很重要。

  • 避免，传统常规的 DH, SRP, J-PAKE 握手和协商
  • 避开任何只使用了块加密算法和srand(time())的密钥协商模式（肯定有漏洞）

###10. 网站安全 应该使用OpenSSL，或者Google的BoringSSL，或者直接使用 AWS的 ELB

此处网站安全，指的是让网站支持HTTPS协议。 如果你不能把这个任务交给Amazon的云服务去做，把难题留给Amazon去解决，那么OpenSSL目前仍然是正确选择。

  • 避免不常见的TLS库，例如polarssl，GnuTLS，MatrixSSL等

###11. 客户端-服务器结构的应用程序的安全： 应该使用TLS

适用场景：如果你以为自己理解了前面关于公钥加密的介绍。。。

通常，在你设计了自己的RSA协议之后的1至18个月，你肯定会发现，你犯了某个错误，使你的协议没有任何安全性。 比如Salt Stack，Salt Stack的协议使用了 e=1 的RSA 公钥。。。

听起来，TLS有下面这些黑历史：

  • The Logjam DH negotiation attack
  • The FREAK export cipher attack
  • The POODLE CBC oracle attack
  • The RC4 fiasco
  • The CRIME compression attack
  • The Lucky13 CBC padding oracle timing attack
  • The BEAST CBC chained IV attack
  • Heartbleed
  • Renegotiation
  • Triple Handshakes
  • Compromised CAs

但是，你仍然应该使用TLS做传输协议，因为：

  • 这些漏洞中的大部分，仅仅是针对浏览器的，因为他们依赖受害者执行攻击者控制的JavaScript脚本，这些JavaScript脚本生成重复的明文，或特定的明文。

  • 这些漏洞中的大部分，其影响都可以被减轻，只需要你在代码和配置里面写死 TLS v1.2, ECDHE，和 AES-GCM就行。这听起来很棘手，但是这远远没有你自己设计使用ECDHE和AES-GCM的传输协议棘手。

  • 在一个自定义的传输协议的场景中，你并不需要依赖CA，你可以用一个自签名证书，嵌入到你的客户端里面。

  • 不要自己设计加密传输协议，这是极其困难而易错的工程难题

  • 使用TLS，但是不要使用默认配置

###12. 在线备份 应该使用Tarsnap

#名词解释

本文的内容比较新，相关中文资料极少，因此文中的名词对读者可能有点陌生，故byron这里介绍一下文中提到的一些名词：

NaCl库: http://nacl.cr.yp.to/ 是密码学学术权威 Daniel J. Bernstein教授 设计的一个密码学算法库，2008年发开始公布。NaCl的特点是：api简洁而易用，高性能，高安全性，主要用于网络通信，加密，解密，签名等，NaCl提供了构建高层密码学工具的核心功能。

libsodium库: https://download.libsodium.org/doc/ libsodium是对NaCl库的一个分支，进一步改进接口易用性，和可移植性。

AEAD: https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html AEAD的概念: 在通常的密码学应用中，Confidentiality (保密) 用加密实现，Message authentication (消息认证) 用MAC实现。这两种算法的配合方式，引发了很多安全漏洞，过去曾经有3种方法：1. Encrypt-and-MAC 2.MAC-then-Encrypt 3.Encrypt-then-MAC ，后来发现，1和2都是有安全问题的，所以，2008年起， 逐渐提出了“用一个算法在内部同时实现cipher+MAC”的idea，称为AEAD(Authenticated encryption with additional data)。 在AEAD这种概念里，cipher+MAC 被 一个AEAD算法替换。

http://en.wikipedia.org/wiki/Authenticated_encryption

ChaCha20-poly1305 ChaCha20-poly1305是一种AEAD，提出者是Daniel J. Bernstein教授，针对移动互联网优化，目前Google对移动客户端的所有流量都使用ChaCha20-Poly1305

AES-GCM AES-GCM是一种AEAD，是目前TLS的主力算法，互联网上https流量的大部分依赖使用AES-GCM。

AES-GCM和ChaCha20-Poly1305的性能对比测试结果:

Chip AES-128-GCM speed ChaCha20-Poly1305 speed
OMAP 4460 24.1 MB/s 75.3 MB/s
Snapdragon S4 Pro 41.5 MB/s 130.9 MB/s
Sandy Bridge Xeon (AESNI) 900 MB/s 500 MB/s

SHA2 http://en.wikipedia.org/wiki/SHA-2

Curve25519 http://cr.yp.to/ecdh.html Curve25519 是目前最高水平的 Diffie-Hellman函数，适用于广泛的场景，由Daniel J. Bernstein教授设计。由于NIST P-256的设计过程不透明，有来历不明的参数，被广泛怀疑有后门，所以设计了Curve25519，Curve25519的设计过程完全公开，没有任何来历不明的参数。 部署情况：http://ianix.com/pub/curve25519-deployment.html

Ed25519 http://ed25519.cr.yp.to/ Ed25519是一个数字签名算法，

  • 签名和验证的性能都极高， 一个4核2.4GHz 的 Westmere cpu，每秒可以验证 71000 个签名
  • 安全性极高，等价于RSA约3000-bit
  • 签名过程不依赖随机数生成器，不依赖hash函数的防碰撞性，没有时间通道攻击的问题
  • 并且签名很小，只有64字节，公钥也很小，只有32字节。 部署情况：http://ianix.com/pub/ed25519-deployment.html

前向安全性 前向安全性( Perfect Forward Secrecy ) http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html 前向安全性指的是，如果攻击者抓取并保存流量，那么将来私钥泄露后，攻击者也无法利用泄露的私钥解密这些流量。

Diffie-Hellman 密钥交换 http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange 在任何一本密码学教材里面都会重点介绍的

constant time compare 针对Timing attack，http://en.wikipedia.org/wiki/Timing_attack （这种攻击真是脑洞大开！） 当一个算法的运行时间和输入数据有关的时候，可以根据运行时间这一信息，破解出密钥等。 典型的，比如要验证一个对称签名，如果你用了C库里面的memcmp()，那你就会被timing attack方式攻击。 因此，涉及到密码学数据的memcmp，必须要用运行时间和输入无关的函数，比如OpenSSL库里面的CRYPTO_memcmp()

@renweibo
Copy link

翻译的很通畅，看完一遍接着看原文，不错，赞一个
“部分愿意也是由于这种向后兼容性”是不是应该是“部分原因也是由于这种向后兼容性”？

@wongsyrone
Copy link

AES-GCM和ChaCha20-Poly1305的性能对比测试结果 的表格格式乱掉了

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment