⼀、对称密码
1、机密性（看不到明⽂）
2、算法：
DES(Data Encryption Standard)：已被暴⼒破解
三重DES(3DES、EDEA）：过程加密（秘钥1）-解密（秘钥2）-加密（秘钥3） （1）DES-EDE2：秘钥1和秘钥3相同和
（2）DES-EDE3：秘钥均不同
特点：安全性可以，但处理速度不⾼。
AES(Advanced Encryption Standard 美国通过组织AES公开竞选算法，免费供全世界使⽤)：取代DES和三重DES的标准算法。
特点：安全、快速
选定的算法为Rijndael算法。
3.DES与AES属于分组密码，只能加密固定长度的明⽂。更多密⽂时需要分组、迭代加密。
如AES分组长度为128⽐特、可以⼀次性加密128⽐特的明⽂，并⽣成128⽐特的密⽂
4.分组密码模式
ECB模式：每个组直接⽤相同秘钥直接加密。绝对不可⽤
CBC模式：推荐
CTR模式：推荐
CFB模式：推荐
OFB模式：推荐
ps：SSL/TLS协议使⽤了CBC模式，⽤了三重DES的3DES_EDE_CBC以及AES_256_CBC
缺点：秘钥配送的问题。-->可以⽤公钥密码（⾮对称加密）解决。
尝试解决配送问题：
（1）事先共享秘钥
当然能见⾯、打电话确认或者邮件确认的⽅式实现共享秘钥⾃然可以，这类场景不会存在配送的问题。
能事先共享秘钥时也有问题：⼈与⼈之间都需要不同的秘钥。数量太多。如果有N个⼈，那么就需要N*(N-1)/2个秘钥
但其他场景，⽐如浏览器与服务器，怎样建⽴起信任？刚认识的朋友之间的消息，如何信任呢？ （2）秘钥分配中⼼：每个⼈都通过中⼼分配。
缺点：数据库保存太多的秘钥、同时秘钥分配中⼼责任重⼤
（3）Diffie-Hellman秘钥交换⽅式
（4）公钥密码（⾮对称加密）
⼆、⾮对称密码（公钥密码）
1、机密性（看不到明⽂）
2、原理：消息接收者A⽣成秘钥对，包含公钥和私钥。公钥发送给消息发送者B。消息发送者B⽤A的公钥对消息进⾏加密，这样A可以
⽤私钥界⾯。
（窃听者能看到公钥，也能看到界⾯的密⽂，但是由于没有私钥，所以⽆法解密出消息）
3.算法：
（1）RSA：使⽤最⼴泛
特点：明⽂、秘钥和密⽂都是数字。
（2）其他算法ElGamal⽅式、Rabin⽅式、椭圆曲线密码⽅式。
椭圆曲线密码⽅式秘钥短但是强度⾼，也被⼴泛使⽤。
70sec SSL/TLS⽤了椭圆曲线Diffie-Hellman秘钥交换（ECDH、ECDHE）和椭圆曲线DSA(ECDSA);
⽐特币使⽤了椭圆曲线DSA⽤于数字签名。
（3）Diffie-Hellman秘钥交换：从公开数字⽆法推断出秘钥。 SSL/TLS中有使⽤到。
1.通讯⽅A⽣成随机数a、通讯⽅B⽣成随机数b。
A发送Diffie-Hellman公开值：A的计算值（G^a / P）、G、P
B发送Diffie-Hellman公开值：B的计算值 (G^b / P)
2. A和B计算出的秘钥是相等的，都是G^(a * b) / p
A的计算秘钥：（B的计算值）^a / P
B的计算秘钥：（A的计算值）^b / P
说明：从公开的数字，是⽆法计算出秘钥的（数学上可以论证）。
Diffie-Hellman秘钥交换计算出的密码是共享密码，⽆法避免中间⼈攻击。
4.缺点：
（1）加密⼤量⽂件时，速度慢（速度远远低于对称密码）
解决：通过混合密码系统解决。
（2）中间⼈攻击
A向B索取公钥时，B发送公钥给A时，被中间⼈C窃听、劫持并保存了B的公钥，C把⾃⼰的公钥给A，这样A通过C的公钥加密的信息C能读到。
C也能给B发送消息。
解决：需要公钥认证。
三、混合密码系统：对称密码 + 公钥密码（⾮对称密码）
1.特点：会话秘钥作为对称密码的秘钥，同时也是公钥密码的明⽂。
（1）会话秘钥（伪随机⽣成器⽣成）
（2）对称密码⽅式（消息，会话秘钥）
（3）公钥密码⽅式（会话秘钥，接受者公钥） - 会话秘钥不会太长
长期考虑：公钥密码强度要⾼于对称密码。
2、应⽤：著名密码软件PGP 和 SSL/TLS都有运⽤。
四、单向散列函数（消息摘要、哈希函数）：不可逆，不能反推出明⽂
1、完整性（检测篡改）
2.特点：
（1）计算速度快、
（2）消息再长计算出的散列值也是固定的长度，如SHA-256长度永远是236⽐特（32字节）
（3）消息不同，那么计算出的散列值也不同
3.应⽤：基于⼝令的加密（PBE）、消息认证码、数字签名、伪随机⽣成器
4.算法：
MD5：已被攻破，不安全
RIPEMD-160：已被攻破，不安全
SHA-1：已被攻破，不安全
SHA-2包括SHA-224、SHA-256、SHA-384、SHA-512 推荐
SHA-3：单向散列函数新标准。Keccak被选定为SHA-3算法。推荐
SHA3-224、SHA3-256、SHA3-384、SHA3-512
缺点：能识别篡改，但是不能识别伪装。
散列算法（签名算法）：MD5、SHA1、HMAC
五、消息认证码（Message Authentication Code）简称MAC：单向散列函数 + 共享秘钥
1.完整性（检测篡改）、认证对⽅⾝份（检测伪装）
羟乙基纤维素钠2.实现⽅式：
（1）单向散列函数（消息 + 共享秘钥）和消息⼀起传送开模
变形：单向散列函数（对称加密（消息，共享秘钥） + 共享秘钥）和对称加密（消息，共享秘钥）⼀起传送
（2）也可以使⽤AES之类的分组密码实现：分组秘钥作为消息的共享秘钥并⽤CBC模式将消息加密。如AES-CMAC是⼀种消息认证码（3）也可以使⽤流密码和公钥密码⽅式。
GCM是⼀种认证加密的⽅式，采⽤AES_128_CTR模式。专门⽤于消息认证码的GCM称为GMAC。
GCM和CCM(CBC count Mode)都被列为推荐的认证加密⽅式。
3.算法：
HMAC:⽤单向散列函数来构建的消息认证码。⽐如HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、HMAC-SHA-512
4.应⽤：
（1）银⾏与银⾏之间的传递消息通过SWIFT(环球银⾏⾦融电信协会)完成，SWIFT使⽤了消息认证码。
（2）IPsec对IP协议的增强，使⽤了消息认证码。
（3）SSL/TLS也使⽤了消息认证码
（4）HMAC算法的基本思想也跟加盐类似，只不过实现⽅式不同。
加盐算是简单粗暴地把原⽂跟盐加在⼀起进⾏hash运算，
⽽HMAC则是将密码key补位，然后与明⽂分组进⾏异或运算，并且将该输出与下⼀个分组进⾏异或运算，直到算出最后的Hash值。
（5）公司系统调⽤接⼝：
案例a.访问外部系统页⾯：A=xxx&B=xxx&time=xxx&sign=HMAC-SHA1(A=xxx&B=xxx&time=xxx , key秘钥)
模式：单向散列函数（消息 + 共享秘钥） + 消息
案例b.⽀付URL：A=xxx&B=xxx&Sign=MD5(A=xxx&B=xxx&Key=xxx)
模式：单向散列函数（消息 + 共享秘钥） + 消息
案例c.接⼝调⽤： MD5( de(content,'UTF-8') + 签名Key) + de(content,'UTF-8')
模式：单向散列函数（消息 + 共享秘钥） + 消息
javascript中⼀般采⽤encodeURIComponent函数对特殊字符进⾏编码。
Java中可以使⽤函数de对特殊字符进⾏编码。
百度地图开放平台中⽤的也是这种，只是⽤的加密⽅式为公钥密码，签名Key为公钥。
案例d.接⼝调⽤：
http时： MD5（AES（content，SECRET_KEY）+ SECRET_KEY）和 AES（content，SECRET_KEY）
参数： accessKey=ACCESS_KEY&signature=MD5（AES（content，SECRET_KEY）+SECRET_KEY）
内容： AES（content，SECRET_KEY）
https时： MD5（content+ SECRET_KEY）和 content
参数： accessKey=ACCESS_KEY&signature=MD5（content+SECRET_KEY）
内容： content
5.缺点：
（1）需要实现共享秘钥，所以同样存在秘钥配送问题。
解决：参见对称加密的⼏种⽅式。
（2）⽆法防⽌否认。
⽐如：A发消息给B，B知道A发了消息，但是A可以抵赖，这时⽆法像第三⽅证明是A发送的(）。
因为A和B都知道密码，有可能是B污蔑A，第三⽅也⽆法判定谁是对的。
解决：数字签名
制钢（3）重放攻击：窃听者把A发送给B的消息，原样发送⼀次。如果是⼀个汇款，那么等于发⽣了多次汇款。
解决：
a.序号⽅式：每次通讯都对消息加⼀个序号，计算MAC时把需要加⼊。下⼀次通讯对序号加1。
难度：序号需要通讯⽅维护和管理。
b.时间戳 - 存在时间同步问题。如果考虑延迟，那么⼜会给重放攻击机会。
c.随机数：客户端保证每次请求的随机数不同 - 时间戳相关的⽣成，服务器存储已经使⽤的随机数。
问题：服务器存储的随机数⽆限⼤。
解决⽅式：时间戳和随机数⼀起使⽤。⽐如服务器设置时间戳的误差为2分钟，那么随机数的存储也只需要存储2分钟。
六、数字签名：单向散列函数 + 公钥密码
1.完整性（检测篡改）、认证对⽅⾝份（检测伪装）、不可否认（对⽅不能否认）
2.原理：
（1）发送⽅A⽣成公钥密码对。
（2）A发送内容包括：A私钥加密消息⽣成签名（签名中包含了A的公钥--供对⽅或第三⽅认证机构验证签名） + 消息
（3）B⽤A的公钥验证A的签名
3.优化：第⼆部有个问题：A私钥直接加密消息是很慢的，所以可以⽤单向散列函数先处理，然后再⽤秘钥加密。如下：
公钥密码（单向散列函数（消息），A私钥） + 消息（推荐）
4.说明
（1）签名并不能保证机密性。如果需要消息的机密性，可以组合对称加密的⽅式。参见后⾯。
（2）签名不能保证消息不被修改，但是被修改后可以识别出来。
(3) 数字签名的不可否认性：因为私钥是发送者才有
（4）数字签名代替纸质签名：存在风险、需要未来完善
（5）软件作者可以加上数字签名，下载软件者，只要验证数字签名就能识别是否被篡改。
（6）数字签名只是能检测是否被篡改，如果软件作者有恶意⾏为，那没办法。
5.缺点：存在中间⼈攻击，需要证明公钥是否合法（公钥是否属于发送者）
解决：为了证明⾃⼰的公钥合法，需要数字证书。
七、公钥证书（证书）：个⼈信息（包含公钥） + 数字签名
1.流程：
（1）A向认证机构注册⾃⼰的公钥。认证机构⽤⾃⼰的私钥给A加数字签名并⽣成证书。
方形气囊
（2）发送消息时不再直接发送⾃⼰的公钥，⽽是发送包含公钥的证书（包含认证机构对发送者公钥的数字签名和发送者的公钥）。
（3）接受⽅可以⽤认证机构的公钥验证数字签名，确认发送⽅公钥的合法性
说明：接收者收到证书并验证合法后，会把发送⽅的秘钥存在电脑，下次通讯直接使⽤。
2.注册公钥时，认证机构需要确认注册者的真实⾝份。可能的⽅式：电话、邮件、查询第三⽅数据库、当⾯认证和⾝份证明等，根据等
级不同等级的认证。
3.证书标准：X.509规范
4.公钥基础设施（Public Key Infrastructure）PKI ：公钥规范总称。X.509也是PKI的⼀项标准。
（1）三要素：
⽤户：⽣成密钥对（也可以由认证机构⽣成）、申请证书、申请作废证书
认证机构：⽤户注册时认证⾝份、颁发证书、作废证书。
仓库：存储证书
（2）证书的层级由上级机构验证下级机构的公钥，迭代下去。直到根CA(Root CA)，根CA⽤⾃⼰的公钥。
当然，这些过程都是电⼦邮件、浏览器等软件完成的。
（3）认证机构只要对公钥进⾏数字签名就可以，任何⼈或者机构都能成为PKI。但如果不采⽤权威的PKI，通讯双⽅可能不会信任。
如对于浏览器访问https协议的⽹页，服务器会把数字证书和⽹页发送回客户端
a.如果不在浏览器“受信任的根证书颁发机构”列表中，会弹出证书的认证机构是否可信任的提⽰。
此时⽤户可以选择不可信任，或者添加到“受信任的根证书颁发机构”列表。
b.如果数字证书信息不对或者证书失效等，浏览器会发出警告。
5.理解
（1）如果能取得可信的公钥，那么不需要认证机构。
（2）当持有可信的认证机构公钥切相信认证机构所进⾏的⾝份认证，可以信任该认证机构颁发的证书以及通讯⽅的公钥
（3）通过⾃⼰的⽅法认证是不安全的- 依靠隐蔽保证安全是错误的
6.应⽤：
（1）正式使⽤的证书⼀般是收费的。赛门铁克提供个⼈证书。
个⼈⽹站或开发者可以⽤腾讯云的免费证书。
（2） USB KEY ⽅式（U盾）：客户端证书和秘钥都放在USB中，不经过⽹络传输。
（3） RSA公司制定的PKCS (Public-Key Cryptography Standards)规范也属于PKI的⼀种，PKCS ⽬前共发布过 15 个标准。
PKCS#7：密码消息语法标准。PKCS#7为使⽤密码算法的数据规定了通⽤语法，⽐如数字签名和数字信封。
PKCS#7提供了许多格式选项，包括未加密或签名的格式化消息、已封装（加密）消息、已签名消息和既经过签名⼜经过加密的消息。
说明：公司中保险电⼦保单中，要求使⽤PKCS#7标准签名。
PKCS ⽬前共发布过 15 个标准：
（1）PKCS#1：RSA加密标准。PKCS#1定义了RSA公钥函数的基本格式标准，特别是数字签名。它定义了数字签名如何计算，包括待签名数据和签名本⾝的格式；
它也定义了PSA公/私钥的语法。
（2）PKCS#2：涉及了RSA的消息摘要加密，这已被并⼊PKCS#1中。
蒸煮炉（3）PKCS#3：Diffie-Hellman密钥协议标准。PKCS#3描述了⼀种实现Diffie- Hellman密钥协议的⽅法。
（4）PKCS#4：最初是规定RSA密钥语法的，现已经被包含进PKCS#1中。
（5）PKCS#5：基于⼝令的加密标准。PKCS#5描述了使⽤由⼝令⽣成的密钥来加密8位位组串并产⽣⼀个加密的8位位组串的⽅法。PKCS#5可以⽤于加密私钥，以便于密钥的安全传输（这在PKCS#8中描述）。
（6）PKCS#6：扩展证书语法标准。PKCS#6定义了提供附加实体信息的X.509证书属性扩展的语法（当PKCS#6第⼀次发布时，X.509还不⽀持扩展。这些扩展因此
被包括在X.509中）。
（7）PKCS#7：密码消息语法标准。PKCS#7为使⽤密码算法的数据规定了通⽤语法，⽐如数字签名和数字信封。PKCS#7提供了许多格式选项，包括未加密或签名的格式化消息、已封装（加密）消息、已签名消息和既经过签名⼜经过加密的消息。
（8）PKCS#8：私钥信息语法标准。PKCS#8定义了私钥信息语法和加密私钥语法，其中私钥加密使⽤了PKCS#5标准。
（9）PKCS#9：可选属性类型。PKCS#9定义了PKCS#6扩展证书、PKCS#7数字签名消息、PKCS#8私钥信息和PKCS#10证书签名请求中要⽤到的可选属性类型。
已定义的证书属性包括E-mail地址、⽆格式姓名、内容类型、消息摘要、签名时间、签名副本（counter signature）、质询⼝令字和扩展证书属性。
（10）PKCS#10：证书请求语法标准。PKCS#10定义了证书请求的语法。证书请求包含了⼀个唯⼀识别名、公钥和可选的⼀组属性，它们⼀起被请求证书的实体签名（证书管理协议中的PKIX证书请求消息就是⼀个PKCS#10）。
（11）PKCS#11：密码令牌接⼝标准。PKCS#11或“Cryptoki”为拥有密码信息（如加密密钥和证书）和执⾏密码学函数的单⽤户设备定义了⼀个应⽤程序接⼝（API）。智能卡就是实现Cryptoki的典型设备。注意：Cryptoki定义了密码函数接⼝，但并未指明设备具体如何实现这些函数。⽽且Cryptoki只说明了密码接⼝，并未定义对设备来说可能有⽤的其他接⼝，如访问设备的⽂件系统接⼝。
（12）PKCS#12：个⼈信息交换语法标准。PKCS#12定义了个⼈⾝份信息（包括私钥、证书、各种秘密和扩展字段）的格式。PKCS#12有助于传输证书及对应的私钥，于是⽤户可以在不同设备间移动他们的个⼈⾝份信息。
（13）PDCS#13：椭圆曲线密码标准。PKCS#13标准当前正在完善之中。它包括椭圆曲线参数的⽣成和验证、密钥⽣成和验证、数字签名和公钥加密，还有密钥协定，以及参数、密钥和⽅案标识的ASN.1语法。
（14）PKCS#14：伪随机数产⽣标准。PKCS#14标准当前正在完善之中。为什么随机数⽣成也需要建⽴⾃⼰的标准呢？PKI中⽤到的许多基本的密码学函数，如密钥⽣成和Diffie-Hellman共享密钥协商，都需要使⽤随机数。然⽽，如果“随机数”不是随机的，⽽是取⾃⼀个可预测的取值集合，那么密码学函数就不再是绝对安全了，因为它的取值被限于⼀个缩⼩了的值域中。因此，安全伪随机数的⽣成对于PKI的安全极为关键。
（15）PKCS#15：密码令牌信息语法标准。PKCS#15通过定义令牌上存储的密码对象的通⽤格式来增进密码令牌的互操作性。在实现PKCS#15的设备上存储的数据对于使⽤该设备的所有应⽤程序来说都是⼀样的，尽管实际上在内部实现时可能所⽤的格式不同。PKCS#15的实现扮演了翻译家的⾓⾊，它在卡的内部格式与应⽤程序⽀持的数据格式间进⾏转换。
⼋、秘钥
1、会话秘钥与主秘钥：Https通讯时，会使⽤会话秘钥（⼀次性秘钥）
2、CEK（Content Encrypting Key 内容加密秘钥）和 KEK（Key Encrypting Key 秘钥加密秘钥)
3.秘钥的⽣成：
（1）随机数⽣成：⽤专门针对密码学⽤途的伪随机⽣成器
（2）基于⼝令的密码：单向散列函数（⼝令 + 盐salt）如PBE
4.配送秘钥：见第⼀节
5.PBE（ Password Based Encryption 基于⼝令的加密）
伪随机数⽣成器-->盐salt
单向散列函数（⼝令 + 盐salt）⽣成KEK(秘钥加密秘钥)
伪随机数⽣成器-->会话秘钥CEK（内容加密秘钥）
对称加密（消息，会话秘钥CEK）
对称加密（会话秘钥CEK，KEK）
说明：
（1）盐salt的作⽤：相当于增加密码的复杂度
（2）盐salt和会话秘钥是随机⽣成的，都是⼀次会话中使⽤，下次会话要⽣成新的。
注意：⼀次会话并不是⼀次通讯。
在会话期间，电脑需要存储盐和加密后的CEK。
（3）pto有实现。
九、伪随机⽣成器：⽤于⽣成秘钥。可以⽤对称密码、单向散列函数或者公钥密码构建。
1.⽅法：
单向散列函数法
密码法
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议