DES(Data Encryption Standard,数据加密标准)是 1977 年发布的第一个公开分组密码标准,分组与密钥都是 64 位,其中密钥的 8 个字节里每个字节有 1 位奇偶校验位,实际有效密钥强度只有 56 位。以今天的算力,DES 已经可以在很短时间内被穷举破解,本工具保留它主要用于兼容老系统、解析历史报文以及教学演示。
| 参数 | 可选值 | 说明 |
|---|---|---|
| 密钥长度 | 8 字节(固定) | 64 位,含 8 位奇偶校验位,有效强度 56 位 |
| 分组长度 | 8 字节(固定) | 64 位 |
| 模式 | ECB / CBC / CFB / OFB / CTR | 与 AES 的模式语义相同 |
| 填充 | PKCS#7 / ZeroPadding / ANSI X9.23 / NoPadding | 流式模式不使用填充 |
| 向量 IV | 8 字节 | ECB 不使用,其余模式必填 |
0x00。如果服务端用 OpenSSL 实现,下面的命令与本工具等价:
openssl enc -des-cbc -K 0123456789abcdef -iv 0102030405060708 -in plain.txt -out cipher.binopenssl enc -d -des-cbc -K 0123456789abcdef -iv 0102030405060708 -in cipher.bin -out plain.txt注意 -K 与 -iv 都必须写成十六进制且不带 0x 前缀,-K 是 16 位十六进制字符(8 字节),-iv 也是 16 位。OpenSSL 默认使用 PKCS#7 填充,与本工具的默认值一致;若要对应 NoPadding,需要额外加 -nopad。
DES 规范里每个密钥字节的最低位是奇偶校验位,用来检测密钥输入错误。实际工程中几乎所有实现(OpenSSL、Java、crypto-js、本工具)都不校验这 8 位,直接按 56 位有效位参与运算。所以 0123456789abcdef 与 0022446688aaccee 这类「校验位不同、有效位相同」的密钥会得到完全相同的密文,这是正常现象,不必担心。
这个工具能替代服务端加密吗?
DES 的分组长度对安全性有什么影响?
NoPadding 模式有什么限制?
密文用 Hex 还是 Base64?
为什么解密后末尾多了一些奇怪的字符?
Java 的 DESede 和这个工具能互通吗?
支持哪些加密模式?
密钥和明文会被上传到服务器吗?
向量 IV 应该填几位?
DES 与 3DES 的密文能互相解密吗?
DES 现在还安全吗?
DES 的密钥为什么是 8 字节?