加密算法(对称、非对称、哈希、签名...)

常见的加密算法有4种:

1、对称加密算法

如AES、ChaCha20

2、非对称加密算法:如RSA

3、哈希算法:SHA-256、SHA-512等

4、消息认证码 / 数字签名

HMAC、RSA签名

对称机密算法

对称加密算法,是加密与解密都用的同一把钥匙。

好处是 :解密速度快 、适合大量数据 加密。
坏处是 :缺点是密钥一旦 露,就全完了。并且如果用GCM的话不好查重

他的安全性挺足的,

我采用的是 AES-256 ,只要密文不丢,2^256次方,现代设备几乎无法破解。

且他有 128192256 这几种类型,其意思就是对一段数据,进行多少论加密。

一般对应的是10轮12轮14轮。选择时一般需要在性能安全性 之间做权衡

加密:

AES是典型的分组加密算法,他会将我的明文以128bit一组,划分多组。

同时用根密钥生成多组密钥,向我选的 AES-256-GCM 就会生成15论密钥。

现在明文被划分 成组,每组需要的对应论数的密钥 也被根密钥生成

接下来就是:先依次进行替换位移列混合 、再用对应密钥加密

对每组都这么重复 。

解密:

解密就是返向操作。

替换:把每个字节采用s-box表替换成其他字节。

位移:就是把每一行数据错位移动。

列混合:把每一列在重新计算一次。

步骤:

复制代码
明文块,128 bit
 ↓
初始 AddRoundKey,用第 0 个轮密钥
 ↓
第 1 ~ 13 轮:
    SubBytes      字节替换
    ShiftRows     行移位
    MixColumns    列混合
    AddRoundKey   加轮密钥
 ↓
第 14 轮:
    SubBytes      字节替换
    ShiftRows     行移位
    AddRoundKey   加轮密钥
    注意:没有 MixColumns
 ↓
密文块

项目中:

我是在AES-256的基础上,采用了GCM 的工作方式

其中AES-256负责加密 数据,GCM 则让它变成认证加密

就是每次加密时会使用nonce,保证同样的密文不同,防破解;

同时生成tag,用来校验密文和ADD是否被篡改;

其中ADD是用来绑定字段名的如"AAD = verify:real_name:v1"

为何不选择chacha20?

首先就是现在cpu大都有专门的AES的硬件加速指令。

其实go有专门的标注库支持,且更容易解释。

chacha20流式的,更适合无AES硬件加速指令的环境下。

非对称加密算法:

比如非对称加密算法 RSA 分为公钥和私钥。

通常是 公钥 用于加密、私钥 用于解密。

像老版本的TLS认证中,就采用过RSA的加密方式。

客户端会通过服务器证书中的RSA公钥加密预主密钥 ,服务器通过RSA私钥解密。

之后就是对称加密进行通话了。

我的项目不选择非对称加密算法的原因是他的计算量有时过大 ,并且不符合 我当前的应用场景

哈希算法

哈希算法就更不用说了,直接将明文,通过哈希计算打碎成哈希值!

哈希算法不是加密计算,也不具有可逆性。通常用于密码存储、完整性校验等。

所以不符合我这种需要解密的场景。

消息认证码 / 数字签名

这个更多是用来防串改的。

向我的项目内,也只有jwt使用了这个。

而我采用的ase-256,使用的gcm工作方式,本身就防串改。

相关推荐
罗西的思考13 小时前
机器人 / 强化学习】HIL-SERL:人类在环驱动的具身智能进化框架
人工智能·算法·机器学习
美团技术团队16 小时前
LongCat 开源 VitaBench 2.0:长期动态智能体基准新标杆
人工智能·算法
To_OC1 天前
LC 207 课程表:刚学图论那会儿,我连这是拓扑排序都没看出来
javascript·算法·leetcode
To_OC1 天前
LC 208 实现 Trie 前缀树:曾被名字劝退,写完发现是送分题
javascript·算法·leetcode
BadBadBad__AK1 天前
线段树维护区间 k 次方和
c++·数学·算法·stl
_清歌2 天前
DSpark 深度解读:DeepSeek-V4 如何用「半自回归」把推理速度提升 85%
算法
统计实现局2 天前
SVD 的三步走:双对角化、Givens 收敛、排序
算法
躬行见万象2 天前
《VLA 系列》UniLab 强化训练 | G1 机器人 |复现
算法
统计实现局2 天前
对称不定分解(Bunch-Kaufman):为什么 Cholesky 不够用
算法