2019年12月19日14:51:00
1. 第1天 - 对称加密
1.1 基础知识点
- 知识点大纲介绍
- 密码的基础概念
- 对称加密
- 非对称加密
- 单向散列函数
- 哈希函数
- 消息认证码
- 数字签名
- 证书
- ssl/tls - https
- 为什么要加密, 以及解决方案
保证数据安全
- 加密三要素
- 明文/密文
- 秘钥
- 定长的字符串
- 需要根据加密算法确定其长度
- 算法
- 加密算法
- 解密算法
- 加密算法和解密算法有可能是互逆的, 也有可能相同
- 常用的两种加密方式
- 对称加密
- 秘钥: 加密解密使用的是同一个秘钥, 秘钥有一个
- 特点
- 双方向保证机密性
- 加密效率高, 适合加密大数据, 大文件
- 加密强度不高, 相对于非对称加密
- 非对称加密
- 秘钥: 加密解密使用的不同的秘钥, 秘钥有两个, 需要使用秘钥生成算法, 得到密钥对
- 公钥 - 可以公开的秘钥
- 公钥加密数据, 解密需要使用私钥
- 私钥 - 需要妥善保管的秘钥, 知道的人越少越好
- 私钥加密, 公钥解密
- 公钥 - 可以公开的秘钥
- 特点:
- 数据的机密性只能单方向保证
- 加密效率低, 适合加密少量数据
- 加密强度高, 相对于对称加密
- 秘钥: 加密解密使用的不同的秘钥, 秘钥有两个, 需要使用秘钥生成算法, 得到密钥对
- 对称加密
- 凯撒密码
恺撒密码(Caesar cipher)是一种相传尤利乌斯·恺撒曾使用过的密码。恺撒于公元前100年左右诞生于古罗马,是一位著名的军事统帅。
恺撤密码是通过将明文中所使用的字母表按照一定的字数“平移”来进行加密的。
- 凯撒密码加解密公式
- 凯撒密码中的加密三要素
- 明文/密文
- 明文: 小写字母表中的数据
- 密文: 大写字母表中的数据
- 秘钥
- 按照上图秘钥为3
- 算法
- 加密: +3
- 解密: -3
- 明文/密文
- 凯撒密码的安全性
不安全
- 密码信息安全常识
- 不要使用保密的密码算法(普通公司和个人)
- 使用低强度的密码比不进行任何加密更危险
- 任何密码总有一天都会被破解
- 密码只是信息安全的一部分
- 密码信息威胁
思考:信息安全处理必须要具备哪些特性?
1.2 对称加密
以分组为单位进行处理的密码算法称为分组密码(blockcipher)
- 编码的概念
G = 1024m
m = 1024kbyte
byte = 8bit
bit 0/1
计算机的操作对象并不是文字,而是由0和1排列而成的比特序列。
将现实世界中的东西映射为比特序列的操作称为编码(encoding)。
加密 -> 编码
解密 -> 解码
hello world -> 比特序列
h -> int 104 ->
- DES -- Data Encryption Standard
- 现在使用DES方式加密,数据还安全吗?
- 不安全, 已经被破解了
- 是不是分组密码?
- 是, 先对数据进行分组, 然后在加密或解密
- DES的分组长度?
- 8byte == 64bit
- DES的秘钥长度?
- 56bit秘钥长度+8bit错误检测标志位 = 64bit == 8byte
- 现在使用DES方式加密,数据还安全吗?
- 3DES -- Triple-DES
- 3DES安全吗?
- 安全, 但是效率低
- 算法描述?
- 进行了3次des加密
- 是不是分组密码?
- 是
- 3DES分组长度?
- 8字节
- 3DES秘钥长度?
- 24字节, 在算法内部会被平均分成3份
- 3DES加密过程?
- 秘钥1 -> 加密, 秘钥2 -> 解密, 秘钥3 -> 加密
- 3DES解密过程?
- 秘钥1 -> 解密, 秘钥2 -> 加密, 秘钥3 -> 解密
- 3DES安全吗?
- AES -- Advanced Encryption Standard
- AES安全吗?
- 安全, 效率高, 推荐使用的
- 是不是分组密码?
- 是
- AES分组长度?
- 128bit = 16字节
- AES秘钥长度?
- 128bit = 16字节
- 192bit = 24字节
- 256bit = 32字节
- go中的秘钥长度只能是16字节
- AES安全吗?
1.3 分组密码的模式
- 按位异或
- 第一步需要将数据转换为二进制
- 按位异或操作符: ^
- 两个标志位进行按位异或操作:
- 相同为0, 不同为1
- 举例:
1 0 0 0 ----> 8 1 0 1 1 ----> 11 -----------------------按位异或一次 0 0 1 1 ----> 3 1 0 1 1 ----> 11 -----------------------按位异或两侧 1 0 0 0 -----> 8 ================================= a = 8 b = 11 a 和 b按位异或1次 ==> 加密 得到的结果再次和 b 按位异或 ===> 解密
- ECB - Electronic Code Book, 电子密码本模式
- 特点: 简单, 效率高, 密文有规律, 容易被破解
- 最后一个明文分组必须要填充
- des/3des -> 最后一个分组填充满8字节
- aes -> 最后一个分组填充满16字节
- 不需要初始化向量
- CBC - Cipher Block Chaining, 密码块链模式
- 特点: 密文没有规律, 经常使用的加密方式
- 最后一个明文分组需要填充
- des/3des -> 最后一个分组填充满8字节
- aes -> 最后一个分组填充满16字节
- 需要一个初始化向量 - 一个数组
- 数组的长度: 与明文分组相等
- 数据来源: 负责加密的人的提供的
- 加解密使用的初始化向量值必须相同
- CFB - Cipher FeedBack, 密文反馈模式
- 特点: 密文没有规律, 明文分组是和一个数据流进行的按位异或操作, 最终生成了密文
- 需要一个初始化向量 - 一个数组
- 数组的长度: 与明文分组相等
- 数据来源: 负责加密的人的提供的
- 加解密使用的初始化向量值必须相同
- 不需要填充
- OFB - Output-Feedback, 输出反馈模式
- 特点: 密文没有规律, 明文分组是和一个数据流进行的按位异或操作, 最终生成了密文
- 需要一个初始化向量 - 一个数组
- 数组的长度: 与明文分组相等
- 数据来源: 负责加密的人的提供的
- 加解密使用的初始化向量值必须相同
- 不需要填充
- CTR - CounTeR, 计数器模式
- 特点: 密文没有规律, 明文分组是和一个数据流进行的按位异或操作, 最终生成了密文
- 不需要初始化向量
- go接口中的iv可以理解为随机数种子, iv的长度 == 明文分组的长度
- 不需要填充
- 最后一个明文分组的填充
- 使用cbc, ecb需要填充
- 要求:
- 明文分组中进行了填充, 然后加密
- 解密密文得到明文, 需要把填充的字节删除
- 要求:
- 使用 ofb, cfb, ctr不需要填充
- 使用cbc, ecb需要填充
- 初始化向量 - IV
- ecb, ctr模式不需要初始化向量
- cbc, ofc, cfb需要初始化向量
- 初始化向量的长度
- des/3des -> 8字节
- aes -> 16字节
- 加解密使用的初始化向量相同
- 初始化向量的长度
1.4 对称加密在go中的实现
- des
- 3des
- aes
# 加密流程: 1. 创建一个底层使用des/3des/aes的密码接口 "crypto/des" func NewCipher(key []byte) (cipher.Block, error) # -- des func NewTripleDESCipher(key []byte) (cipher.Block, error) # -- 3des "crypto/aes" func NewCipher(key []byte) (cipher.Block, error) # == aes 2. 如果使用的是cbc/ecb分组模式需要对明文分组进行填充 3. 创建一个密码分组模式的接口对象 - cbc func NewCBCEncrypter(b Block, iv []byte) BlockMode # 加密 - cfb func NewCFBEncrypter(block Block, iv []byte) Stream # 加密 - ofb - ctr 4. 加密, 得到密文
非对称加密
2. 对称加密的弊端
- 秘钥分发困难
- 可以通过非对称加密完成秘钥的分发
https
Alice 和 Bob通信, Alice给bob发送数据, 使用对称加密的方式
- 生成一个非对称的秘钥对, bob生成
- bob将公钥发送给alice
- alice生成一个用于对称加密的秘钥
- alice使用bob的公钥就对称加密的秘钥进行加密, 并且发送给bob
- bob使用私钥就数据解密, 得到对称加密的秘钥
- 通信的双方使用写好的秘钥进行对称加密数据加密
1. 非对称加密的秘钥
- 不存在秘钥分发困难的问题
1.1 场景分析
数据对谁更重要, 谁就拿私钥
- 直观上看: 私钥比公钥长
- 使用第三方工具生成密钥对: 公钥文件xxx.pub xxx
- 通信流程, 信息加密 (A写数据, 发送给B, 信息只允许B读)
A: 公钥
B: 私钥
- 登录认证 (客户端要登录, 连接服务器, 向服务器请求个人数据)
客户端: 私钥
服务器: 公钥
- 数字签名(表明信息没有受到伪造,确实是信息拥有者发出来的,附在信息原文的后面)
- 发送信息的人: 私钥
- 收到信息的人: 公钥
- 网银U盾
- 个人: 私钥
- 银行拿公钥
1.2 使用RSA非对称加密通信流程
要求: Alice 给 bob发送数据, 保证数据信息只有bob能看到
1.3 生成RSA的秘钥对
3.1 一些概念
- x509证书规范、pem、base64
- pem编码规范 - 数据加密
- base64 - 对数据编码, 可逆
- 不管原始数据是什么, 将原始数据使用64个字符来替代
- a-z A-Z 0-9 + /
- 不管原始数据是什么, 将原始数据使用64个字符来替代
- ASN.1抽象语法标记
- PKCS1标准
3.2 密钥对生成流程
- 生成私钥操作流程概述
- 使用rsa中的GenerateKey方法生成私钥
func GenerateKey(random io.Reader, bits int) (priv *PrivateKey, err error)
- rand.Reader -> import "crypto/rand"
- 1024 的整数倍 - 建议
- 通过x509标准将得到的ras私钥序列化为ASN.1 的 DER编码字符串
func MarshalPKCS1PrivateKey(key *rsa.PrivateKey) []byte
- 将私钥字符串设置到pem格式块中
初始化一个pem.Block块
type Block struct { Type string // 得自前言的类型(如"RSA PRIVATE KEY") Headers map[string]string // 可选的头项 Bytes []byte // 内容解码后的数据,一般是DER编码的ASN.1结构 }
- 通过pem将设置好的数据进行编码, 并写入磁盘文件中
func Encode(out io.Writer, b *Block) error
- out - 准备一个文件指针
- 生成公钥操作流程
- 从得到的私钥对象中将公钥信息取出
type PrivateKey struct { PublicKey // 公钥 D *big.Int // 私有的指数 Primes []*big.Int // N的素因子,至少有两个 // 包含预先计算好的值,可在某些情况下加速私钥的操作 Precomputed PrecomputedValues }
- 通过x509标准将得到 的rsa公钥序列化为字符串
func MarshalPKIXPublicKey(pub interface{}) ([]byte, error)
- 将公钥字符串设置到pem格式块中
type Block struct {
Type string // 得自前言的类型(如"RSA PRIVATE KEY")
Headers map[string]string // 可选的头项
Bytes []byte // 内容解码后的数据,一般是DER编码的ASN.1结构
}- 通过pem将设置好的数据进行编码, 并写入磁盘文件
func Encode(out io.Writer, b *Block) error
1.4. RSA加解密
1. RSA加密
- 将公钥文件中的公钥读出, 得到使用pem编码的字符串
-- 读文件
- 将得到的字符串解码
-- pem.Decode
- 使用x509将编码之后的公钥解析出来
-- func ParsePKCS1PrivateKey(der []byte) (key *rsa.PrivateKey, err error)
- 使用得到的公钥通过rsa进行数据加密
2. RSA解密
- 将私钥文件中的私钥读出, 得到使用pem编码的字符串
- 将得到的字符串解码
- 使用x509将编码之后的私钥解析出来
- 使用得到的私钥通过rsa进行数据解密
5. 哈希算法
1.5 概念
称谓: 单向散列函数, 哈希函数, 杂凑函数, 消息摘要函数
接收的输入: 原像
输出: 散列值, 哈希值, 指纹, 摘要
1.6 单向散列函数特性
- 将任意长度的数据转换成固定长度的数据
- 很强的抗碰撞性
- 不可逆
- MD4/MD5
- 不安全
- 散列值长度: 128bit == 16byte
- sha1
- 不安全
- 散列值长度: 160bit == 20byte
- sha2 - 安全
- sha224
- 散列值长度: 224bit == 28byte
- sha256
- 散列值长度: 256== 32byte
- sha384
- 散列值长度: 384bit == 48byte
- sha512
- 散列值长度: 512bit == 64byte
1.7 go中使用单向散列函数
// 第一种方式, 直接调用sum // 适用于数据量比较小的情况 func Sum(data []byte) [Size]byte // 第二种方式 // 1. 创建哈希接口对象 func New() hash.Hash type Hash interface { // 通过嵌入的匿名io.Writer接口的Write方法向hash中添加更多数据,永远不返回错误 io.Writer // 返回添加b到当前的hash值后的新切片,不会改变底层的hash状态 Sum(b []byte) []byte // 重设hash为无数据输入的状态 Reset() // 返回Sum会返回的切片的长度 Size() int // 返回hash底层的块大小;Write方法可以接受任何大小的数据, // 但提供的数据是块大小的倍数时效率更高 BlockSize() int } type Writer interface { Write(p []byte) (n int, err error) } // 2. 往创建出的哈希对象中添加数据 hash.Hash.Write([]byte("添加的数据...")) hash.Hash.Write([]byte("添加的数据...")) hash.Hash.Write([]byte("添加的数据...")) hash.Hash.Write([]byte("添加的数据...")) // 3. 计算结果, md5就是散列值 md5 := hash.Sum(nil); // 散列值一般是一个二进制的字符串, 有些字符不可见, 需要格式化 // 格式化为16进制的数字串 - 0-9, a-f func EncodeToString(src []byte) string // 数据转换完成之后, 长度是原来的2倍
- 计算一个大文件比如1G文件的散列值
- 使用udp的方式分发秘钥, 进行一个对称加密的通信
- 服务器
- 生成密钥对
- 公钥发送给客户端
- 客户端
- 客户端收到了公钥
- 生成一个秘钥 - 用于对称加密
- 使用公钥加密, 发送给服务器
- 服务器
- sha224
3. 复习
- 概念
- 加密三要素
- 明文/密文
- 秘钥
- 算法
- 对称加密和非对称加密
- 对称加密: 加解密使用同一个秘钥, 1个
- 效率高
- 非...: 密钥对
- 公钥加密, 私钥解密
- 私钥加密, 公钥解密
- 对称加密: 加解密使用同一个秘钥, 1个
- 对称加密中的公开的加密算法
- des
- 分组长度: 8字节
- 秘钥长度: 8字节
- 3des
- 分组长度: 8字节
- 秘钥长度: 24byte
- aes
- 分组长度: 16字节
- 秘钥长度: 16字节, 24字节, 32字节
- 在go的api中只能使用16字节
- des
- 对称加密的分组模式
- EBC - 不推荐使用
- CBC - 常用的方式
- 准备的数据:
- 初始化向量iv - 字符数组
- 长度 == 明文分组长度
- 加解密初始化向量值必须相同
- 秘钥
- 根据加密算法定
- 初始化向量iv - 字符数组
- 准备的数据:
- 加密三要素
===========================
- OFB - 不推荐使用
- CFB - 不推荐使用
- CTR - 推荐使用, 效率最高
常用密码技术
1 密码
1.1 发送者、接收者和窃听者
请想象一个Alice向Bob发送电子邮件的场景。在这个场景中,发出邮件的Alice称为 发送者(sender),而收到邮件的Bob则称为 接收者(receiver)。
在讲解发送者、接收者的概念时,用邮件这个例子会比较便于理解,但实际上发送者和接收者这两个术语的使用范围并不仅仅局限于邮件。当某个人向另一个人发送信息时,发出信息的人称为发送者,而收到信息的人称为接收者。另外,被发送的信息有时也统称为 消息(message)。
- Alice向Bob发送邮件
邮件是通过互联网从Alice的计算机发送到Bob的计算机的。在发送邮件时,邮件会经过许多台计算机和通信设备进行中转,在这个过程中,就存在被恶意窃听者(eavesdropper)偷看到的可能性。
- Eve(窃听者)看到邮件的内容
窃听者Eve并不一定是人类,有可能是安装在通信设备上的某种窃听X,也可能是安装在邮件软件和邮件服务器上的某些程序。
尽管邮件内容原本应该只有发送者和接收者两个人知道,但如果不采取相应的对策,就存在被第三方知道的风险。
1.2 加密和解密
Alice不想让别人看到邮件的内容,于是她决定将邮件进行加密(encrypt)后再发送出去。
加密之前的消息称为明文(plaintext),加密之后的消息称为密文(cipher-text)。
我们看到明文可以理解其中的含义,而看到密文则无法理解其中的含义。
- 明文加密之后就会变成看不懂的密文
Bob收到了来自Alice的加密邮件,但作为接收者的Bob也是无法直接阅读密文的,于是
Bob需要对密文进行解密(decrypt)之后再阅读。解密就是将密文恢复成明文的过程。
- 密文解密之后就变成了原来的明文
将消息加密后发送的话,即使消息被窃听,窃听者得到的也只是密文,而无法得知加密前的明文内容
- 将消息加密后发送, 窃听者只能得到密文
在上述场景中,Alice将邮件进行加密,而Bob则进行解密,这样做的目的,是为了不让窃听者Eve读取邮件的内容Alice和Bob通过运用密码(cryptography)技术,保证了邮件的机密性(confidentiality)。
1.3 秘钥
1.3.1 密码算法
用于解决复杂问题的步骤,通常称为算法(algorithm)。从明文生成密文的步骤,也就是加密的步骤,称为“加密算法",而解密的步骤则称为“解密算法"。加密、解密的算法合在一起统称为密码算法。
1.3.2 秘钥
密码算法中需要密钥(key)。现实世界中的“钥‘‘,是像 ?? 这样的形状微妙而复杂的小金属片。然而,密码算法中的密钥,则是像203554728568477650354673080689430768这样的一串非常大的数字。
- 加密、解密与秘钥
无论是在加密时还是在解密时,都需要知道密钥。
正如保险柜的钥匙可以保护保险柜中存放的贵重物品一样,密码中的密钥可以保护你的重要数据。即使保险箱再坚固,如果钥匙被盗, 里面的贵重物品也会被盗。同样地我们也必须注意不要让密码的密钥被他人窃取。
1.4 凯撒密码
恺撒密码(Caesar cipher)是一种相传尤利乌斯·恺撒曾使用过的密码。恺撒于公元前100年左右诞生于古罗马,是一位著名的军事统帅。
恺撤密码是通过将明文中所使用的字母表按照一定的字数“平移”来进行加密的。比如在日语(例如平假名)或者汉语(例如汉语拼音)或者英文字母表中都可以用同样的思路来实现恺撒密码。
为了讲解方便,我们用小写字母(a,b,c,…)来表小明文,用大写字母(A,B,C,...)来表示密文。
现在我们将字母表平移3个字母,于是,明文中的a在加密后就变成了与其相隔3个字母的D,以此类推。b变成E,c变成F,d变成G......v变成Y,w变成Z,而x则会回到字母表的开头而变成A,相应地,y变成B,z变成C。通过下图我们可以很容易地理解“平移"的具体工作方式。
1.4.1 凯撒密码的加密
这里,我们假设要保密的信息为monkey d luffy这个男孩的名字。我们暂且不管这个名字到底代表一位真实的男性,还是只是一种暗号,只考虑将它在保密的状态下发送给接收者。
此时,明文包含下列12个字母:monkey d luffy, 接下来我们对明文中的字母逐一加密:
m ---> P
o ---> R
n ---> Q
k ---> N
e ---> H
y ---> B
d ---> G
l ---> O
u ---> X
f ---> I
f ---> I
y ---> B
这样,明文 monkey d luffy 就被转换成了密文PRQNHB G OXIIB,monkey d luffy这个词我们能够看懂,但
PRQNHB G OXIIB就看不懂了。
恺撒密码中,将字母表中的字母平移这个操作就是密码的算法,而平移的字母数量则相当于密钥。在上面的例子中,密钥为3(如下图)。
1.4.2 凯撒密码的解密
现在,假设接收者已经收到了密文PRQNHB G OXIIB,由于密文本身是看不懂的,因此必须将它解密成明文。
恺撒密码的解密过程是使用与加密时相同的密钥进行反向的平移操作。用刚才的例子来说,只要反向平移3个字母就可以解密了。
P ---> m
R ---> o
Q ---> n
N ---> k
H ---> e
B ---> y
G ---> d
O ---> l
X ---> u
I ---> f
I ---> f
B ---> y
这样我们就得到了明文monkey d luffy。
在这个场景中, 秘钥3必须由发送者和接收者事先约定好。
1.5 密码信息安全常识与威胁
1.5.1 密码信息安全常识
在继续下面的内容之前,我们先来介绍一些关于密码的常识。刚刚开始学习密码的人常常会对以下这几条感到不可思议,因为它们有悖于我们的一般性常识。
- 不要使用保密的密码算法
- 使用低强度的密码比不进行任何加密更危险
- 任何密码总有一天都会被破解
- 密码只是信息安全的一部分
不要使用保密的密码算法
很多企业都有下面这样的想法:
“由公司自己开发一种密码算法,并将这种算法保密,这样就能保证安全。然而,这样的想法却是大错特错,使用保密的密码算法是无法获得高安全性的。我们不应该制作或使用任何保密的密码算法,而是应该使用那些已经公开的、被公认为强度较高的密码算法。
这样做的原因主要有以下两点:
- 密码算法的秘密早晚会公诸于世
从历史上看,密码算法的秘密最终无一例外地都会被暴露出来。例如: RSA公司开发的RC4密码算法曾经也是保密的,但最终还是有一位匿名人士开发并公开了与其等效的程序。
一旦密码算法的详细信息被暴露,依靠对密码算法本身进行保密来确保机密性的密码系统也就土崩瓦解了。反之,那些公开的算法从一开始就没有设想过要保密,因此算法的暴露丝毫不会削弱它们的强度。
- 开发高强度的密码算法是非常困难的
- 要比较密码算法的强弱是极其困难的,因为密码算法的强度并不像数学那样可以进行严密的证明。密码算法的强度只能通过事实来证明,如果专业密码破译者经过数年的尝试仍然没有破解某个密码算法,则说明这种算法的强度较高。
- 稍微聪明一点的程序员很容易就能够编写出“自己的密码系统"。这样的密码在外行看来貌似牢不可破,但在专业密码破译者的眼里,要破解这样的密码几乎是手到擒来。
- 现在世界上公开的被认为强度较高的密码算法,几乎都是经过密码破译者长期尝试破解未果而存活下来的。因此,如果认为“公司自己开发的密码系统比那些公开的密码系统更强”,那只能说是过于高估自己公司的能力了。
- 试图通过对密码算法本身进行保密来确保安全性的行为,一般称为隐蔽式安全性(securitybyobscurity),这种行为是危险且愚蠢的。
- 反过来说,将密码算法的详细信息以及程序源代码全部交给专业密码破译者,并且为其提供大量的明文和密文样本,如果在这样的情况下破译一段新的密文依然需要花上相当长的时间,就说明这是高强度的密码。
使用低强度的密码比不进行任何加密更危险
一般人们会认为.就算密码的强度再低,也比完全不加密要强吧?其实这样的想法是非常危险的。
正确的想法应该是:与其使用低强度的密码,还不如从一开始就不使用任何密码这主要是由于用户容易通过“密码”这个词获得一种“错误的安全感”。对于用户来说,安全感与密码的强度无关,而只是由“信息已经被加密了”这一事实产生的,而这通常会导致用户在处理一些机密信息的时候麻痹大意。
任何密码总有一天会被破译
如果某种密码产品宣称“本产品使用了绝对不会被破解的密码算法”,那么你就要对这个产品的安全性打个问号了,这是因为绝对不会被破解的密码是不存在的。
无论使用任何密码算法所生成的密文,只要将所有可能的密钥全部尝试一遍,就总有一天可以破译出来。因此,破译密文所需要花费的时间,与要保密的明文的价值之间的权衡就显得非常重要。
密码只是信息安全的一部分
我们还是回到Alice给Bob发送加密邮件的例子。即便不去破解密码算法,也依然有很多方法能够知道Alice所发送的邮件内容, 例如:
攻击者可以不去试图破译经过加密的邮件,而是转而攻击Alice的电脑以获取加密之前的邮件明文。
上面提到的攻击手段,都与密码的强度毫无关系。要保证良好的安全性,就需要理解“系统”这一概念本身的性质复杂的系统就像一根由无数个环节相连组成的链条,如果用力拉,链条就会从其中最脆弱的环节处断开。因此,系统的强度取决于其中最脆弱的环节的强度。
最脆弱的环节并不是密码,而是人类自己。
1.5.2 密码信息威胁
我们将信息安全所面临的威胁与用来用对这些威胁的密码技术直接的关系用一张图标来表示出来。
原文地址:https://www.cnblogs.com/oneapple/p/12068034.html