一、对称密码
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方式、椭圆曲线密码方式。
椭圆曲线密码方式秘钥短但是强度高，也被广泛使用。
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
缺点：能识别篡改，但是不能识别伪装。
五、消息认证码（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）公司系统调用接口：
a.发票打印 - 访问Vat页面：A=xxx&B=xxx&time=xxx&sign=HMAC-SHA1(A=xxx&B=xxx&time=xxx , key秘钥)
模式：单向散列函数（消息 + 共享秘钥） + 消息
b.支付平台微信扫码支付：A=xxx&B=xxx&Sign=MD5(A=xxx&B=xxx&Key=xxx)
模式：单向散列函数（消息 + 共享秘钥） + 消息
c.影像上传接口： MD5( URLEncoder.encode(content,'UTF-8') + 签名Key) + URLEncoder.encode(content,'UTF-8')
模式：单向散列函数（消息 + 共享秘钥） + 消息
javascript中一般采用encodeURIComponent函数对特殊字符进行编码。
Java中可以使用函数URLEncoder.encode对特殊字符进行编码。
百度地图开放平台中用的也是这种，只是用的加密方式为公钥密码，签名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）javax.crypto有实现。
九、伪随机生成器：用于生成秘钥。可以用对称密码、单向散列函数或者公钥密码构建。
1.方法：
单向散列函数法
密码法
ANSI X9.17 :被用于了PGP中。
2.java.util.Random 不能用于安全相关用途。可以用java.security.SecureRandom替代
十、PGP密码软件-密码技术的完美组合。（GnuPG也是一款类似的软件）
1.功能：对称密码、公钥密码、数字签名、单向散列函数、证书、压缩、文本数据（二进制与文本数据的相互转换）、钥匙串管理、大文件拆分与拼合。
2.涉及公钥合法性时，PGP没有使用认证机构、而是采用了信任网的方式（PGP用户相互信任对方）。
私钥的保存：
（1）基于口令的密码： 单向散列函数（口令 + 盐salt） 生成私钥的加密密钥
（2）用PEB对私钥进行加密。
使用时：用口令获取PPE，然后对加密后的私钥进行解密。
十一、SSL/TLS （Secure Socket Layer 安全套阶层 Transport Layer Secure 传输层安全）
1.SSL/TLS之上承载的HTTP、SMTP、POP3。
TLS是在SSL3.0基础上设计的协议，相当于SSL3.1。
2.先进行SSL/TLS层协议，然后在执行其上的协议。比如http三次握手
3.TLS生成主密码方式：
（1）生成预备主密码的两种方式
先生成，然后用公钥密码方式传输。
Diffie-Hellman秘钥交换直接生成。
（2）主密码由预备主密码 + 客户端随机数 + 服务器随机数生成，用密码套件中定义的单向散列函数（如SHA-256）计算生成。
十二、虚拟货币-比特币
1.比特币是一种基于P2P网络（由所有比特币用户组成）的支付结算系统。
2.区块链是保存比特币交易的公共账簿，记录了迄今为止所有的交易。而且是透明的，任何人都可以验证交易。
3.比特币地址：交易是在比特币地址直接完成的。多数情况下会为每一笔交易创建不同的地址。但是在比如捐赠等场景中，也会反复使用同一地址。
比特币的地址是有公钥的散列生成。
椭圆曲线DSA的公钥输入SHA-256和RIPEMD-160两个单向散列函数计算散列值，附加一些信息后再用Base58Check进行编码，转换成字符串。
4.比特币的客户端：钱包。 用户通过钱包生成秘钥对，公钥用于接收比特币，私钥用于支付比特币。
5.区块链维护：
（1）区块中任意一比特被修改，那么必须重建区块之后的所有区块的数据。
（2）需要有人把新的区块添加到区块链中，称为挖矿。成功添加新的区块的矿工能获取奖励。
（3）同一时间点出现了多个符合要求的散列值，那么区块链可能产生分支。
通常需要确认，通常选择把计算量大的分支继续工作，压制区块链继续分支。
6.交易
使用了数字签名技术。其中数字签名的算法为椭圆曲线DSA
十三、常识
1.不要使用保密的密码算法，公开的算法都是世界公认的，安全性更有保障。
2.任何密码总有一天被破解
标签：PKCS,公钥,加密,证书,技术,秘钥,密码 来源： https://www.cnblogs.com/caoshouling/p/11438256.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。