加解密-引文
密码算法主要提供的能力 [1]
-
可靠性
-
是系统安全的最基于要求之一,是所有网络信息系统的建设和运行目标。网络信息系统的可靠性测度主要有三种:抗毁性、生存性和有效性。
-
-
可用性
-
是网络信息可被授权实体访问并按需求使用的特性。即网络信息服务在需要时,允许授权用户或实体使用的特性,或者是网络部分受损或需要降级使用时,仍能为授权用户提供有效服务的特性。可用性是网络信息系统面向用户的安全性能。网络信息系统最基本的功能是向用户提供服务,而用户的需求是随机的、多方面的、有时还有时间要求。可用性一般用系统正常使用时间和整个工作时间之比来度量。
-
-
保密性
-
是网络信息不被泄露给非授权的用户、实体或过程,或供其利用的特性。即,防止信息泄漏给非授权个人或实体,信息只为授权用户使用的特性。保密性是在可靠性和可用性基础之上,保障网络信息安全的重要手段。
-
-
完整性
-
是网络信息未经授权不能进行改变的特性。即网络信息在存储或传输过程中保持不被偶然或蓄意地删除、修改、伪造、乱序、重放、插入等破坏和丢失的特性。完整性是一种面向信息的安全性,它要求保持信息的原样,即信息的正确生成和正确存储和传输
-
-
真实性:使用密码算法相应方式可以确定远程用户或系统的身份。比如web服务器提供的SSL证书能够保证用户连接的是正确的服务器。
-
不可抵赖性(不可否认性)
-
在网络信息系统的信息交互过程中,确信参与者的真实同一性。即,所有参与者都不可能否认或抵赖曾经完成的操作和承诺。利用信息源证据可以防止发信方不真实地否认已发送信息,利用递交接收证据可以防止收信方事后否认已经接收的信息。
-
-
可控性
-
对网络信息的传播及内容具有控制能力的特性。
-
-
密钥管理
-
密钥管理是安全处理密钥的生命周期。密钥的产生、装入、存储、备份、分配、更新、吊销、销毁等内容,其中分配和存储最困难。
-
-
密钥分层管理
-
可以使用不同的密钥保护不同的秘密,即使攻击者攻破了一个密钥,受威胁的只是这个攻破密钥所保护的秘密,其它的秘密任然安全。
-
-
工作密钥/会话密钥
-
真正用来加密明文的密钥,为了安全,更换比较频繁,每次会话均会变更。
-
-
密钥加密密钥
-
密钥加密密钥主要用于生成会话密钥,其生存周期相对较长。
-
-
根密钥/主密钥
-
使用频次最少,一般仅在启动或初始化时使用,用于保护其他密钥,生存周期最长,需要的安全性最高。
-
保证以上能力的关键,就是选择正确的加密算法。 |
📌 术语定义
-
对称算法
-
对称算法的加密密钥只能从解密密钥中推算出来,反过来也成立。在大多数对称算法中,加、解密密钥是相同的。
-
-
非对称算法
-
也叫公开密钥算法:用于加密的密钥与用于解密的密钥不同,而且解密的密钥不能根据加密密钥计算出来。之所以叫做公开密钥算法,是因为加密密钥能够公开,及陌生人用加密密钥加密信息,单只用于相应的解密密钥才能解密信息。
-
-
哈希算法
-
是一种将不同长度的数据映射成固定长度数据的算法。
-
-
消息认证码
-
密码学上的一种数据校验和,通过使用对称密钥来检测数据是否发生意外或者有意的篡改。消息验证码简称MAC。也可理解为在哈希算法基础上多了一层加密。
-
-
流密码
-
流密码也成为序列密码,是对称密码算法的一种,他是用算法和密钥一起产生的一个随机码流,将其与数据流XOR产生加密后的数据流。
-
-
分组密码
-
是对称算法的一种,它将明文分成多个等长的组,并用相同的算法对每组进行加密。
-
-
工作模式
-
是指使用分组密码算法对数据进行加密转换的方法。常见的工作模式有ECB、CBC、CFB、OFB等模式。
-
-
初始向量(IV,Initial Vector)
-
是许多工作模式中用于随机化加密的一块数据,因此可以由相同的明文、相同的密钥产生不同的密文。
-
-
填充(Padding)
-
分组密码算法只能对数据长度为分组长度整数倍的数据进行处理,填充就是保证数据长度符合这种要求的一种方法。
-
-
盐值(Salt)
-
通过在口令任意位置插入字符串,让哈希后的结果和原始口令的哈希结果不相符,这种过程称之为"加盐"。这个字符串就是盐值。
-
-
安全强度(Security Strength)
-
是用来衡量密码算法或者密码系统的安全性,它是对破解密码算法或者系统所需要的工作量的一个数值度量。
-
-
口令(Password)
-
是指用于身份认证、鉴权或者导出加密密钥的字符串,可由字母、数字和符合组成。
-
-
密钥(Key)
-
是一个结合密码算法一起使用的参数,可以通过它加密或恢复数据明文,没有它则不行。
-
🔗 规范约束
算法的选择
选择标准的公开密码算法
选择标准的公开密码算法而非私有的、非标准的密码算法,原因主要有
-
非密码学专家设计的密码算法,难以达到密码学领域的专业性要求
-
技术上未经业界的分析验证,有存在未知的缺陷的可能
-
违背了加密算法要公开透明的原则
举例
-
未公开的、自行设计的密码算法,简单例子:变形/字符串移位/替换等方式。网易云音乐因自行使用特定字符异或处理,造成易破解,带来不可估量的经济损失。
-
自行对标准密码算法进行改造的。如自定义哈希算法将md5算法最后一位固定置为0,可能造成哈希冲突,无法公开算法等。
-
用编码的方式(如Base64编码)实现数据伪加密。编码
≠
加密,编码后实际未进行任何加密。 -
用差错控制编码(如奇偶校验、CRC)实现完整性校验。这类校验在恶意伪造场景非常无力。
优先使用强密码算法
密码算法分类
-
不安全密码算法
-
随着密码技术的发展以及计算机及计算能力的提升,一些密码算法现今已经不适用于安全领域。
-
如:
MD5
算法,由于算法本身被发现弱点,现在已经可以人为构造出两个具有相同MD5校验值的信息。 -
又如
DES
算法,因为计算能力提升导致对其暴力破解成为可能,现有的暴力破解设备能将破解DES的时间减少在一天以内。 -
继续使用这些不安全的密码算法,可能有数据不安全的风险。
-
-
可用密码算法
-
未证实存在安全问题,但使用不当容易引起安全威胁的算法
-
安全强度不足导致生命周期很快结束的算法,随着计算机硬件水平的发展,未来可能容易被破解。
-
-
强密码算法
-
经业界普遍认可,安全强度满足大部分场景要求,安全性可以得到保证的算法。
-
下表基于 NIST SPS800-57
[2]
定义的安全强度以及对应的生命周期,列出了常见 不安全密码算法 、 可用密码算法 和推荐使用的 强密码算法 。
加密类型 | 不安全密码算法 | 可用密码算法 | 强密码算法 |
---|---|---|---|
对称加密-分组加密 |
|
3DES(K1,K2,K3各不相同) |
AES(≥128bits) |
对称加密-流加密 |
|
RC4(≥128bits) |
AES(≥128bits) |
哈希算法 |
|
SHA-1 |
SHA256或以上 |
非对称加密 |
|
|
|
数字签名 |
|
|
|
密钥交换 |
DH(<1024bits) |
DH(1024bits) |
|
建议使用的算法列表
算法类别 | 加密算法 | 最低强度 | 建议默认强度 |
---|---|---|---|
对称加密算法 |
AES(SM4) |
256 |
256 |
非对称算法 |
|
2048 |
2048 |
非对称算法 |
ECC |
192 |
192 |
数字签名算法 |
DSA |
1024 |
2048 |
数字签名算法 |
ECDSA |
192 |
256 |
不可逆HASH算法 |
SHA |
224 |
256 |
基于哈希的消息验证码算法 |
HMAC-SHA |
224 |
256 |
密钥交换算法 |
ECDH |
256 |
256 |
-
RC4很容易用错,流密码加密推荐使用AES加密算法代替。
-
SHA-1用于数字签名时为不安全算法,用于消息认证、密钥导出函数、随机数生成以及hash-only场景时可作为遗留使用的算法。
其他TODO Blowfish/Twofish
核心要素
密码系统的安全主要由以下两点保证:
-
选择了安全的加解密算法
-
正确使用算法
安全随机数
随机数应用生成IV、盐值、密钥等,都属于密码算法用途。不安全的随机数使得密钥、IV值等可被全部或部分预测。要生成密码学意义上的安全随机数,必须保证其不可预测性。 |
故应利用硬件接口等安全随机数生成方式来生成。如下
-
OpenSSL中
RAND_bytes()
-
JDK的
java.security.SecureRandom()
-
类Unix平台
/dev/random
文件; -
Windows平台
RtlGenRandom()
;
使用对称-分组密码算法时,优先使用 AES-CBC
分组密码算法有多种工作模式,不同工作模式有特定的适用场景。CBC模式适用性最好,是使用最广泛的工作模式,故优先选择。 |
ECB模式对于同样的明文会产生同样的密文块,不能提供严格的数据保密性,不能抵抗替换攻击,攻击者可以调换加密块的顺序而不被发现。因此,应禁止使用ECB模式。
对于有并行处理,加密认证等明确的特殊需求的,可以选择具备对应特性的工作模式。如下:
-
需要进用行认证加密时,可使
GCM
和CCM
模式 -
需要对数据进行并行处理,预计算或需要支持随机访问时,可使用
CTR
模式 -
存储设备加密时,可使用
XTS-AES
模式 -
图像、语音等信号流加密时,可使用
OFB
模式,即使个别出错也不影响效果
分组密码算法使用到的IV值必须不可预测
CBC和CFB模式下对于任意给定的明文,作用于明文的IV在产生之前都不应该被预测出来。对称分组密码算法中使用的IV 值如果能被预测出来,就容易受到选择明文攻击,攻击者可以通过不断的构造明文去加密,以此来猜测某一密文对应的明文。对于数据库中保存的一些敏感字段(如用户口令、金额、投票结果等)其加密使用的IV值必须不可预测,否则其明文很容易被猜测出来。
-
IV
使用安全的随机数。具体的参考 随机数小节 的说明。 -
IV
随机,即便在使用同一密钥的情况下。攻击者也无法得到密文间的相关性。 -
对于一些特殊的情景,如
CTR
模式下的IV
值,如果每次加密使用不同的密钥,则无需为随机数 -
另外对于
OFB
模式来说,只要保证每次加密的IV值的唯一性即可。
对称密码算法中在使用同一密钥时,不应当两次使用同一个 IV
加密数据
初始化向量IV值与密钥相比有不同的安全性需求,IV通常无需保密,不应当在使用同一密钥的情况下两次使用同一IV来加密数据。因为同一密钥情况下重用IV,则相同的密文块加密前的明文块是相同的,这样就可能会遭受选择明文攻击。另外对于某些特定算法或工作模式同一密钥的情况下重用IV会带来严重安全漏洞。如: |
-
使用
OFB
工作模式或使用流密码(如RC4
)加密时,如果使用相同的IV值和密钥来加密两条消息,攻击者知道了加密后的两个消息之一的明文,就可以对另外一个消息包进行解密; -
对于CFB工作模式而言,如果使用相同的IV值和密钥来加密两条消息,攻击者知道了加密后的两个消息包之一的明文,则另一个消息包的首个明文块信息泄露。
使用 AES
分组密码算法来代替 RC4
流密码算法
|
使用RC4算法加解密应满足以下规则(标准协议要求要支持RC4算法的场景除外)
-
对不同数据使用同一主密钥加密时必须使用不同的IV值和主密钥一起生成密钥流。如果不使用IV或IV值不变,攻击者知道了其中一个加密数据的明文,就可以对其它密文进行解密。IV可以是安全的随机数或者计数器。
-
必须使用安全的哈希函数作用于主密钥和IV,再生成密钥流。如果主密钥与IV只是简单拼接异或,也可能造成主密钥泄露。
-
不适用生成密钥流的前512个字节。由于RC4算法生成密钥流开始的一些比特随机性较差,在实际使用中应弃掉前512字节。
-
保证加密数据的完整性。由于RC4的工作方式,攻击者很容易通过翻转密文的比特来翻转明文对应位置的比特,即很容易遭受比特翻转攻击(bit-flipping attack)。因此保证消息的完整性就格外重要。建议使用消息认证码来保证消息的完整性。
非对称密码算法
非对称密码算法主要用于提供 |
规则:使用 RSA
算法时要选取合适的公共指数 e
说明:公共指数e位长越小, |
实际使用中e推荐取值为216+1,既0x10001。
使用 RSA
算法进行加密操作时,应选择OAEP填充方式
对数据进行填充要非常谨慎,因为一些有经验的黑客有可能从中找到一些线索,早期的PKCS#1填充标准就曾受到一种自适应选择明文攻击的威胁。 |
使用DSA签名时要保证签名的r、s值均不为0
使用DSA进行数字签名时,签名的结果为(r,s),这里需要对r、s值进行校验,若r=0或者s=0,则重新选择随机数k生成签名。因为如果r=0,签名结果不依赖于私钥,很容易计算出k,进而伪造签名。如果s=0,则容易求取私钥进行伪造签名。 |
在同时进行对称算法加密和非对称算法签名时,使用先签名后加密的方式
先签名后加密是指非对称算法先对消息进行签名,然后将签名和消息一起进行对称算法加密。如果采用先加密后签名的方式,接收方只能知道该消息是由签名者发送过来的,但并不能确定签名者是该消息的创建者。比如在发送一个认证凭据时采用先加密后签名,消息在发送过程中就有可能被三方截获并将签名修改为自己的签名。然后发送给接收方。第三方就有可能在不需知道认证凭据的情况下通过这种方式来通过认证获取权限。 |
采用先非对称算法签名后非对称算法加密方式可以避免这类问题的发生,因为只有在知道消息内容的情况下才能对其进行签名。
不要使用二进制域的ECDSA认证方式
ECDSA使用了椭圆曲线密码学原理(ECC),ECC有素数域和二进制域两种实现方式,后者在专门的硬件上实现计算更为有效,前者通常在通用的处理器上更为有效。 2011年3月19日,两位研究者在他们发表的IACR论文中证明:通过时间攻击从使用带二进制域ECDSA认证的OpenSSL的服务器中恢复出TSL私钥是可能的。这种威胁的OpenSSL 1.0.0e版本中已经修复。出于安全考虑,不要再使用二进制域的ECDSA签名认证方式。 |
哈希函数
哈希函数将任意长度的输入转换为固定长度的值,哈希算法也叫摘要算法、单向散列函数、数字指纹算法。许多提供安全服务的算法中都将哈希算法作为其算法的一部分。比如数字签名、基于哈希的消息验证码、密钥导出函数和随机数生成器。口令的单向哈希保存也需要用到哈希函数。
口令单向哈希的生成,必须使用基于口令的KDF算法
口令属于个人敏感数据,即使是系统管理员也不应该知道用户的明文口令。所以应只存储口令单向哈希值。但单纯的口令哈希值,无法防止彩虹表攻击(彩虹表就是一个庞大的、针对各种可能的字母组合预先计算好的哈希值的集合)。增加了盐值计算出来的哈希值,可以防止相同口令生成相同的哈希值,但是在hashcat这种GPU计算资源的暴力破解工具面前,安全性仍不足。所以口令哈希的计算在增加盐值的基础上还要考虑迭代计算。 在这种场景下可以使用基于口令的密钥导出算法,如PBKDF2和scrypt等。PBKDF2是一个密钥导出函数,并且已在RFC2898标准中定义。它使用最为广泛,能被大多数算法库所支持,因此优先推荐使用PBKDF2。 |
规则描述:
-
口令的单向哈希生成应使用基于口令的密钥导出算法,如PBKDF2和scrypt等;
-
使用PBKDF2时迭代次数缺省建议为50000次,对于有性能约束的软件(如嵌入式系统)可以适当降低,推荐至少5000次;
-
哈希函数推荐选择SHA256或更安全的算法;
-
盐值至少8字节,应使用安全的随机数。 例外情况:只有针对客户端才可以例外(如:客户端需要记住口令或者登陆凭证等用于自动登录的场景,以及认证协议有约束的场景如:digest-MD5认证)除外。
消息认证码(MAC)用于保证数据的真实性和完整性。大多数MAC算法用来检测数据在产生MAC值到校验MAC值期间是否发生修改。它检测不到产生MAC值之前发生的修改。本小节将介绍MAC应用的典型误用。
禁止将hash(key||message)方式当做MAC来使用
这种方式是指直接将密钥与消息进行拼接后再进行哈希运算达到计算MAC的目的。这种方式存在风险,因为安全的MAC函数必须保证其不可伪造性,即在不知道密钥key的情况下,攻击者很难构造出新的消息和齐对应的MAC值,单采用这种方式攻击者可以达到这种目的。 如果将hash(key||message)作为MAC来使用,很容易遭受消息扩展攻击(length extension attack)。攻击者如果知道hash(key||message)和message,可以在不知道key的情况下计算得到h=hash(key||message||padm||message’)(其中padm为计算hash(key||message)时的填充,message’可为任意消息),然后可将message||padm||message’和h一起发送给接收者。接收者察觉不到message已经被修改。 |
因此,不要将hash(key||message)作为MAC来使用,应使用标准的MAC算法(如HMAC和CMAC)。
在同时进行加密操作和MAC计算时,要使用不同的密钥
加密操作和MAC计算使用相同的密钥在某些情况下会引入安全问题,如CBC分组加密结合CBC-MAC一起使用时,如果使用同一密钥,将会使得认证功能失效。加密操作和MAC计算使用同一密钥本身也违背了密钥用途单一性的原则,如果其中一种用途被破解后另外一种用途也同时失效。 |
推荐的做法:一种简单的方式是使用带认证的加密模式,如GCM和CCM。这种方式用户只需一个密钥和IV就可得到密文和MAC值,也能保证其安全性。单这两种模式只有部分算法库和 协议支持(如OpenSSL的EVP接口,TLS v1.2)。对于新的应用,如果所选用的算法库和协议支持,应尽可能使用这两种加密模式。
还有一种更通用的做法是使用密钥导出函数KDF,通过一个主密钥导出来个子密钥,分别用于加密和MAC计算。这种做法适用于算法库或协议不支持带认证的加密模式以及需要考虑兼容性的场景。此时的加密和MAC操作推荐使用Encrypt-then-MAC方式,即先对消息进行加密然后计算密文的MAC值。相比其他方式(Encrypt-and-MAC、Encrypt-then-MAC),Encrypt-then-MAC还具备IND-CPA(Indistinguishability under chosen-plaintext attack)安全特性。强烈建议MAC是将加密用的IV和密文结合在一起计算MAC值,这样可同时保证IV的完整性。
密钥管理 [1]
对密码算法中用到的密钥进行安全管理对整个系统的安全性至关重要。如果使用不恰当的密钥管理方式,使用再强的密码算法也无济于事。 |
-
密钥应以不可预知的方式生成
-
密钥需要有过期时间,且过期时间要小于字典穷举攻击获得密钥的最短时间
-
密钥存储必须进行加密等操作,除非在有一定安全的容器中
-
密钥分离:一个群组间的密钥泄漏不应影响其他群组的密钥
-
密钥需要一定的备份机制,能够恢复,但不应因此降低密钥管理的安全性
-
每一个密钥都有特定的用途,密钥不能用于其他的目的
-
密钥不能被非授权地查询、修改、替换、删除或插入
-
系统应能够检测出任何密钥的泄露,当检测到密钥泄露或疑似泄露时,应立即停止使用
典型场景应用指导
不需要还原口令的存储(单向哈希)
举例:用户登录口令、支付密码
方案:口令单向哈希场景下推荐使用PBKDF2算法,通过输入口令(明文)生成哈希值。 PBKDF2算法(RFC2898)是一个密钥导出算法。即可用于导出密钥,也可用于口令保存。计算公式 DK=PBKDF2(P, S, c, Hash, dkLen)
输入: P:口令,字节串; S :盐值,字节串; c :迭代次数,正整数; dkLen :导出密钥的指定字节长度,正整数; 输出: DK:导出密钥,长度dkLen字节。在这里就是最终存储的口令哈希值。 采用PBKDF2算法可以有效增加彩虹表攻击的难度。通过增加迭代次数增加暴力破解的耗时,单对完成一次认证的性能影响不大。
连续哈希一个值,值域会缩小,虽然缩小的程度很小很小。这样做的好处是什么呢?破解者也需要同样的哈希次数,延长了时间。无论是直接碰撞还是建立彩虹表,都要付出更加 x 循环次数 倍的时间。目前黑客手里都有循环几十次的彩虹表,所以只连续哈希数次,还不如不循环。如果计算能力足够,非用这种方法,起码上千到几万次。循环太多了的话,计算开销划不着,值域缩小也会比较明显。所以不建议单纯的连续哈希。 |
要点:
-
Hash函数:选择SHA256或更安全的哈希算法。
-
迭代次数:增加迭代次数绝对安全,也可以采取连续哈希时,每次加盐,加不同的盐,只需进行几次运算即可。
-
Salt:至少8字节,且为安全随机数。
业界迭代册数取值普遍 10000+
可还原口令的存储(对称加密)
举例:数据库密码、第三方系统的口令(远程登录密码)、系统间秘密数据交互交互、密钥、银行卡号、余额等
方案:采取封装好的AES方法
要点:
-
AES 算法、CBC模式
-
分组填充方式使用PKCS#7中定义的填充方式(填充的值为填充的字节数,当应用环境要求密文与明文长度相同时,可使用特殊的填充方式CBC-CS(具体参考标准SP800-38A-Addemdura)
-
加密中所需的IV值,由安全随机数发生器产生
文件加密
举例:系统间传输文件,重要文件存储。
方案:对文件的加密要使用对称加密,推荐使用AES加密算法的CBC模式。为防止文件过大,无法一次性读入内存,可采用将文件加密处理的方式,加密后密文合并到一个文件。IV可附加到文件密文一起保存。 如果是采用用户输入口令方式解密文件,则文件加密密钥可由口令派生出的密钥(如使用PBKDF2函数)进行对称加密后和IV等信息一起保存在文件头或尾部。
要点:
-
对文件等大量数据进行加密时使用CBC模式;
-
加密中所需的IV值,由安全随机数发生器产生。不同文件IV不能相同。
-
分块读取文件内容进行加解密处理后再保存合并到一个文件。
安全数据非对称加解密
举例:客户端与服务器传递密钥、传递用户口令
方案:服务器端产生公私钥对,将公钥传递给客户端。公私钥对可在程序中产生也可使用外部工具产生。公钥不需要加密,私钥在服务器端需要加密保存。客户端给服务器发送敏感数据时用服务器公钥进行加密,服务器端用私钥进行解密。
要点:
-
为保证112位的安全强度,使用
RSA
算法时密钥长度至少为2048
。 -
使用
RSA
算法时使用OAEP
填充方式。使用OAEP
填充方式时输入明文长度必须比RSA
密钥长度少41字节,对于2048
位的密钥,明文长度必须少于2048/8-41=215
字节。输入大于相应长度时必须进行切割再填充。 -
使用
RSA
算法时的公共指数e通常 取值为216+1,即0x1001
。
网络安全传输
在非信任的网络中,需要进行敏感数据的批量传输,如果可能的话,尽量使用已经成熟的安全标准,而不是自己在构造一套。例如,尽量使用SSL/TLS、SSH、IPSec等。
以下列举 SSL
/TLS
部署 最佳实践
[3] 中推荐内容:
-
为确保SSL提供了必要的安全性,在部署SSL/TLS协议时,所有的服务器上,都使用
2048
位的私钥; -
保护私钥,对私钥的可访问范围做最小化,建议的策略包括:
-
将私钥存储到备份系统时,需要用口令加密保护以防止被泄密;
-
一旦发生泄密,吊销所有的旧证书并且为新的证书生成密钥对;
-
每年更新证书,而且永远使用新的私钥。
-
-
从可信CA获得证书; 默认情况下使用最新的TLS协议版本,使用一些老的版本保持与用户的互通性。SSL/TLS协议一共有5个版本: SSL v2, SSL v3, TLS v1.0, TLS v1.1和TLS v1.2,其中:
-
SSL v2不安全,一定不能使用
-
SSL v3和TLS v1.0不安全,不能使用
-
TLS v1.1和TLS v1.2没有已知的安全问题(TLSv1.1大体上还可以使用。并不知道其用于HTTP之外的协议时存在什么安全缺陷)
-
TLS v1.2 首选
-
-
只使用安全的加密套件。推荐使用128比特或更高安全强度的加密套件,其它的必须 限制使用,如:
-
匿名DH(ADH)套件不提供认证功能;
-
NULL套件不提供加密功能;
-
出口密钥交换套件使用了容易被破解的认证机制;
-
使用弱加密算法的套件使用的加密算法(如DES、3DES、RC4)容易被破解。
-
📚 附录
常见算法简介
算法名称 | 标准编号 | 标准名称 | 发布机构 | 发布时间 |
---|---|---|---|---|
DES |
FIPS 46-3 |
Data Encryption Standard |
NIST |
1999 |
AES |
FIPS 197 |
Advanced Encryption Standard |
NIST |
2001 |
3 DES |
SP 800-67 Rev.1 |
Triple Data Encryption Algorithm |
NIST |
2012 |
RC4 |
Ron Rivest |
1994 |
||
SM4 |
GM/T 0002-2012 |
SM4分组密码算法 |
国家密码管理局 |
2012 |
|
PKCS#IV2.2 |
PKCS#IV2.2 |
|
2012 |
RFC3447 |
Public-Key Cryptography Standards(PKCS) #1: |
IETF |
2003 |
|
DSA |
FIPS 186-3 |
Digital Signature Standard (DSS) |
NIST |
2009 |
FIPS 186-3 Proposed Change |
DRAFT Proposed Change Notice for Digital Signature Standard (DSS) |
NIST |
2012 |
|
ECDSA |
ANS X9.62-2003 |
Public-Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm(ECDSA) |
ANSI |
2005 |
SM2 |
GM/T 0003-2012 |
SM2椭圆曲线公钥密码算法 |
国家密码管理局 |
2012 |
DH |
RFC2631 |
Diffie-Hellman Key Agreement Method |
IETF |
1999 |
PKCS#3 V1.4 |
Diffie-Hellman Key Agreement Standard |
|
1993 |
|
IEEE Std 1363-2000 |
Standard Specifications for Public Key Cryptography |
IEEE |
2000 |
|
SHA1 |
FIPS 180-4 |
Secure Hash Standard(SHS) |
NIST |
2012 |
RFC 3174 |
US Secure Hash Algorithm |
IETF |
2001 |
|
SHA2 |
FIPS 180-4 |
Secure Hash Standard(SHS) |
NIST |
2012 |
MD5 |
RFC 1321 |
The MD5 Message-Digest Algorithm |
IETF |
1992 |
SM3 |
GM/T 0004-2012 |
SM3密码杂凑算法 |
国家密码管理局 |
2012 |
HMAC |
FIPS 198-1 |
The Key-Hash Message Authentication Code(HMAC) |
NIST |
2008 |
RFC 2104 |
HMAC Keyed-Hashing for Message Authentication |
IETF |
1997 |
|
工作模式 |
SP 800-38A |
Recommendation for Block Cipher Modes of Operation: Methods and Techniques |
NIST |
2001 |
SP 800-38A-Addendum |
Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode |
NIST |
2010 |
|
SP 800-38B |
Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication |
NIST |
2005 |
|
SP 800-38C |
Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality |
NIST |
2004 |
|
SP 800-38D |
Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC |
NIST |
2007 |
|
SP 800-38E |
Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices |
NIST |
2010 |
|
SP 800-38F |
Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping |
NIST |
2012 |
|
PHE基于口令加密 |
PKCS#5 V2.1 |
Password-based Encryption Standard |
|
2012 |
RFC 2829 |
Authentication Methods for LDAP |
IETF |
2000 |
|
消息格式 |
PKCS#7 V1.5 |
Cryptographic Message Syntax Standard |
|
1993 |
RFC 3852 |
Cryptographic Message Syntax (CMS) |
IETF |
2004 |
|
KDF密钥导出函数 |
PKCS#5 V2.1 |
Password-based Encryption Standard |
|
2012 |
RFC 5869 |
HMAC-based Extract-and-Expand Key Derivation Function (HKDF) |
IETF |
2010 |
|
SP 800-108 |
Recommendation for Key Derivation Using Pseudorandom Functions |
NIST |
2009 |