本文简单总结几种常用的安全算法
- 摘要算法
- 对称加密算法
- 非对称加密算法
- 数字签名
- 数字证书
web安全系列目录
数字摘要
实现
- 将任意长度的明文通过单向hash函数摘要成固定长度的串。
Hash（明文）-->固定长度的摘要
特点
- 无论明文多长，计算出来的摘要长度总是固定的。hash（‘a’）和hash（‘aaaaaaaaaaa’）形成的摘要长度是一样的
- 一般明文不同，计算出来的摘要也不同。也就是相同的明文，计算出来的摘要是一样的，不同的明文形成的摘要一般是不一样（好的hash函数不会发生碰撞）
- 只能进行正向的消息摘要。也就是说从消息摘要中不能恢复成原来的明文。
数字摘要算法
- md5
- sha
md5
-
将待加密串进行md5计算形成128比特位（32位16进制）的摘要。
字符串：jiajun md5摘要：a51c0678c060ae4c4630d930fe83102c
SHA-1
- 将待加密串进行SHA计算后形成160比特位（40位16进制）的摘要。
-
对比md5，摘要信息更长，运算过程更复杂，速度更慢，但相对也更加安全。
字符串：jiajun SHA-1摘要:26352d75496932fd05e65724610ce1aaadf9259c
base64不是一种加密算法而是一种编码算法
- 将二进制数据编码成ascll码。比如说我们将图片以json的形式上传到服务器，那么可以将图片二进制数据通过base64编码转化为二进制。
- base64是可逆的，通过解码算法可以恢复成二进制数据，所以根本不能加密。
彩虹表破解hash算法
- 上面提到的两种数字摘要算法md5和sha-1都是不可逆算法，那么如何破解呢？彩虹表是一种破解的方式。
| 明文 | hash算法 | 密文 |
|---|---|---|
| xxx | md5 | xxx |
| xxx | sha-1 | xxx |
- 彩虹表破解法通过这样的一张表进行查询，比如攻击者拿到了一个用户密码密文，是通过md5算法加密的，那么他可以在这样的一张表进行查询，从而查到密码的明文。
- 彩虹表是不断的积累的过程，表的内容不断丰富，从而破解的机率慢慢提高。
- 如果用户的密码是常见的密码，比如说生日，攻击者知道有些用户会用生日作为密码，那么攻击者可以提前将这些生日组合进行计算，提前记录在表里面。那么在彩虹表查询很快可以查询的到密码明文。而如果密码较为复杂，如果泄露了密文，根据生成的密文在彩虹表进行查询，是很难查到的（因为表里面并没有）。这也就是为什么我们为用加盐的方法降低破解率的原因了。
对称加密
实现
- 发送方和接收方约定一个密钥，生成加密密文发送。接收方接受后，使用相同的密钥和加密算法的逆算法进行解密。通俗将，我给小花写一封情书，然后放在一个上锁的小箱子，经过多人的，最后到达小花，小花通过相同的钥匙打开箱子。但是如果钥匙中途被人捡到，那么情书就公开了。所谓对称指的是加密解密用同一个加密密钥。
特点
- 算法是公开的，加密速度快。
- 一旦泄露密钥，因为算法是公开的，所以可以轻松解密。
应用分析
- A向B发送秘密文件，这个时候可以采用对称加密算法，没有密钥者不能解密文件。
- 如果密钥泄露那么文件可以被解密，而且随着技术的发展，如果采用穷举暴力解密也是有可能。
- 如果A向很多人发送秘密文件，那么需要多次约定。
对称加密算法
- DES算法，密钥64位
- AES算法，，密钥长度之处128,192,256三种，加密强度更高。
DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。
3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。
AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高；
非对称加密
实现
- A向B发送消息，B先产生一个公钥和私钥，然后将公钥公开，A获得公钥。
- 然后用公钥进行加密，然后将密文发送给B。
- B得到后用私钥进行解密。
特点
- 非对称加密更加复杂，所以加密解密速度没有对称加密快，但是也更加安全。
非对称加密算法
- RSA算法
应用分析
- 即使中途有人截获文件，因为没有私钥，并且加密算法复杂，解密是很困难的。
- 如果A向多人发送秘密文件，那么他不需要多次约定的过程，从公钥库根据接收方的公钥分别进行加密就行。
数字签名
实现
- A给B发送信息，A生成公钥和私钥，将公钥公开。
- A对发送消息进行数字摘要算法，然后再通过私钥进行加密。
- A将加密后的密文和原文发送给B
- B收到后，对密文用公钥进行解密，获得串C，再用原文进行摘要算法，获得串D，然后对比C D。这样就能确认A的身份。
- 数字签名：将明文进行摘要，然后再通过私钥进行加密的结果
数字签名算法
- MD5withRSA算法
- SHA1withRSA算法
应用分析
- B收到A的文件，B想确认是A发送的，那么可以根据数字签名方式，根据A的公钥进行解密然后比较，因为A的私钥是不公开的，这样匹配成功就能确认是A发送的。
数字证书
实现
- A给B发送消息，A生成公钥和私钥。
- A将公钥，还有公钥持有者，签名算法，过期时间等信息发送给CA（数字证书认证机构）
- CA认可信息之后，通过CA的私钥进行签名，这时候数字证书就产生了。
- 接着A将明文，明文数字签名，和数字证书一起发送给B
- B接受到后，通过CA的公钥进行解密，进行第一次校验，校验数字证书。
- 验证成功后，进行第二次检验，提取数字证书中的公钥，对密文进行解密。
应用分析
- 在数字签名的基础上，再发送一个数字证书，这样的话接收方不需要维护一个公钥库，通过CA验证后在数字证书提取，获得公钥。
https://security.stackexchange.com/questions/35210/encrypting-using-aes-256-do-i-need-iv/35216#35216
Suppose you encrypt two messages with the same key, and the two messages begin with the same 16 bytes of plaintext. (16 bytes is the block size for AES, regardless of the key size.) Will the first block of ciphertext be the same? If it is, you're already leaking some information to the attacker. Whether this information is sensitive or not depends on your application, but it's already a bad sign. If the encryption leaks more than the sign of the messages, it's not doing its job.
The basic idea of an IV is to prepend a bit of random content to each message, in a principled way. How this works precisely depends on the mode. (The core AES operation only works on 16-byte blocks. A mode is a way to extend this to longer messages.) For example, with CBC, the encryption of each block is computed from the key, the plaintext block and the ciphertext of the previous block; for the very first block, the IV is used instead of the ciphertext of the non-existent previous block. The IV is normally sent in cleartext alongside the ciphertext, usually it is sent a the first 16 bytes of the encrypted message.
CTR mode technically uses a counter and not an IV, but operationally they work very similarly: a 16-byte random value is generated at random by the sender and sent at the beginning of the encrypted message. With CTR mode, reusing that value for another message is catastrophic, because CTR works by XORing the plaintext with a pseudorandom stream deduced from the key and counter. If you have two encrypted messages that use the same counter value, their XOR is the XOR of the two plaintexts.
There are more attacks against improperly-chosen IVs than I've listed here. Generate a random IV for each message (using a cryptographic-quality random generator, the same you'd use to generate a key), and you'll be fine.
There is one exception: if you generate a fresh key for each message, you can pick a predictable IV (all-bits 0 or whatever). You still need to use a mode with an IV (ECB is not fine, for example it exposes repetitions in the plaintext since two identical input blocks will have the same encryption). That's a rare case though (it arises for storage, not for communication).
Note that encryption a priori only ensures the confidentiality of the data, not its integrity. Depending on what you do with the data, this may be a problem. In particular, if an attacker can submit tentative ciphertexts to be decrypted, or can provide additional plaintexts to be encrypted, this can expose some information. Some modes such as EAX and GCM provide authenticated encryption: a ciphertext will only be decrypted if it's genuine. Use one of these if possible.
Note also that AES-128 is just as secure in practice as AES-256.
If you aren't comfortable with what you're doing, try to use some high-level library rather than grappling with the crypto directly.
大意是说 IV 没什么特殊用处，就是让相同的明文，经过使用不同的 IV 再加密后，其秘文每次都是不一样的，这样防止模式攻击。 另外，IV 需存放在秘文之前，且IV采用明文存储。 至于里面说 AES-128和AES-256安全程度一样，个人觉得还是有点差异的，不然位数不同就没意义了，但对个人使用者来说，差异不大。
PKCS5Padding与PKCS7Padding的理解
在采用AES、DES等块加密时，有时需要对不满足一个整块（block）的部分需要进行填充，我们常用的填充的方式就包括ZeroPadding、PKCS5Padding与PKCS7Padding，这里面有什么区别呢。
填充方式的区别
ZeroPadding，数据长度不对齐时使用0填充，否则不填充。使用0填充有个缺点，当元数据尾部也存在0时，在unpadding时可能会存在问题。
我们这里主要讨论PKCS7Padding与PKCS5Padding。
（1）PKCS7Padding，
假设每个区块大小为blockSize
<1>已对齐，填充一个长度为blockSize且每个字节均为blockSize的数据。
<2>未对齐，需要补充的字节个数为n，则填充一个长度为n且每个字节均为n的数据。
（2）PKCS5Padding，PKCS7Padding的子集，只是块大小固定为8字节。
两者的区别在于PKCS5Padding是限制块大小的PKCS7Padding
具体代码实现
按照以上的定义，我们用golang实现如下：
func PKCS7Padding(cipherText []byte, blockSize int) []byte { padding := blockSize - len(cipherText)%blockSize padText := bytes.Repeat([]byte{byte(padding)}, padding) return append(cipherText, padText...) } func PKCS5Padding(cipherText []byte) []byte { return PKCS7Padding(cipherText, 8) }
在解密后，需要将填充的字符去掉，取最后一位即知道存在多少个补充位，但一般需要多取几位校验一下最后一位是否为真实数据，一般首尾和中间都取一下，甚至将全部padding进行对比。