DES加解密介绍：经典对称加密算法原理与3DES演进

在 AES 成为加密标准之前，DES（Data Encryption Standard）是全球应用最广泛的对称加密算法。尽管 DES 已不再被视为安全的选择，但它深刻影响了现代密码学的发展。本文介绍 DES 的算法原理、工作模式、安全缺陷，以及它的演进方案 3DES，帮助开发者理解遗留系统中的 DES 使用场景和迁移方向。

DES 与相近机制的边界

• DES（对称加密）：使用 56 位有效密钥，对 64 位数据块进行加密。曾广泛用于金融、政府和商业系统，但已不适合新系统。
• AES（后继标准）：密钥更长（128/192/256 位），安全性远高于 DES。新系统应使用 AES-GCM，而非 DES。
• 3DES（过渡方案）：通过三次 DES 运算延长有效密钥，暂时性提升了安全性，但计算开销大三倍。
• 密码哈希（bcrypt / argon2）：DES 可逆加密，不可用于口令存储；口令应使用单向哈希。

简单记忆：DES 已过时、3DES 仅用于兼容遗留系统、新项目一律使用 AES。

DES 算法原理

DES 由 IBM 在 1970 年代设计，1977 年被 NIST 采纳为联邦标准。它采用 Feistel 网络结构，是一种分组密码。

分组大小与密钥

与 AES 不同（128 位分组、128/192/256 位密钥），DES 的 64 位分组和 56 位有效密钥是其安全性不足的结构性原因。

Feistel 网络结构

DES 采用 Horst Feistel 提出的 Feistel 网络。每一轮将 64 位数据块分为左右各 32 位的两半：

1. 右半部分（R）直接传递给下一轮的左半部分。
2. 右半部分经轮函数 F(R, Ki)（含扩展置换、S 盒替换、P 盒置换）后与左半部分异或，结果作为下一轮的右半部分。

Feistel 结构最大的优点是加密与解密使用相同结构（仅逆转子密钥顺序即可），这在 1970 年代的硬件实现中极大降低了复杂度。

S 盒——DES 安全性的核心

DES 共有 8 个 S 盒（Substitution Box），每个将 6 位输入映射为 4 位输出。S 盒的设计参数最初未公开，引发 NSA 是否植入后门的猜测。后续差分密码分析（1990 年公开）表明，DES 的 S 盒实际对差分攻击有较强的抵抗力——可知 NSA 在 1970 年代已掌握了差分密码分析技术，但未公开。

工作模式

与 AES 类似，DES 本身只处理 64 位分组，需配合工作模式处理任意长度数据：

需注意：DES 没有原生 AEAD 模式（如 AES-GCM）。若在遗留系统中必须使用 DES-CBC，应额外配合 HMAC 以保证完整性。

DES 的安全缺陷

56 位密钥空间不再安全

2⁵⁶ ≈ 7.2 × 10¹⁶ 的密钥空间在 1970 年代看似充足，但：

• 1998 年：EFF 的 Deep Crack 专用硬件以约 56 小时暴力破解 DES，成本约 25 万美元。
• 2006 年：COPACOBANA 项目使用 FPGA 集群，约 9 天内可完成破解，成本降至约 1 万美元。
• 当前：GPU 集群或云服务可在数小时至数日内暴力破解 DES 密钥。

NIST 于 2005 年正式撤销 DES 标准，仅保留 3DES 用于遗留兼容，且于 2023 年底建议完全弃用 3DES。

64 位分组带来碰撞风险

在 CBC 模式下，当加密数据量超过约 32 GB 时，生日攻击导致的密文块碰撞概率显著增大，可能泄露部分明文信息。AES 的 128 位分组将此阈值提升至约 256 EB，为实际使用提供了充足余量。

3DES：有限的安全增强

3DES（Triple DES，又称 TDEA）通过三次 DES 运算提升安全性：

密文 = E(K₃, D(K₂, E(K₁, 明文)))

即加密-解密-加密（EDE）结构。使用中间解密步骤是为了兼容单 DES：当 K₁ = K₂ = K₃ 时，3DES 等价于单 DES。

3DES 的主要问题在于性能：三次完整的 DES 运算使加密速度下降到单 DES 的三分之一。在软件实现中，AES-128 通常比 3DES 快数倍且更安全。

Go 实现示例（DES-CBC，仅供参考）

以下示例使用 Go 标准库演示 DES-CBC 加解密。代码仅用于理解遗留系统或教育用途，新项目不应使用 DES。

package cryptoutil

import (
	"crypto/cipher"
	"crypto/des"
	"crypto/rand"
	"encoding/base64"
	"errors"
	"io"
)

// EncryptDESCBC 使用 DES-CBC 模式加密，返回 Base64 编码的 IV+密文。
func EncryptDESCBC(plaintext, key []byte) (string, error) {
	if len(key) != 8 {
		return "", errors.New("DES key must be exactly 8 bytes")
	}

	block, err := des.NewCipher(key)
	if err != nil {
		return "", err
	}

	// PKCS#7 填充
	blockSize := block.BlockSize()
	padding := blockSize - len(plaintext)%blockSize
	padText := make([]byte, len(plaintext)+padding)
	copy(padText, plaintext)
	for i := len(plaintext); i < len(padText); i++ {
		padText[i] = byte(padding)
	}

	// 生成随机 IV
	iv := make([]byte, blockSize)
	if _, err := io.ReadFull(rand.Reader, iv); err != nil {
		return "", err
	}

	mode := cipher.NewCBCEncrypter(block, iv)
	ciphertext := make([]byte, len(padText))
	mode.CryptBlocks(ciphertext, padText)

	// 存储为 IV + 密文
	result := append(iv, ciphertext...)
	return base64.StdEncoding.EncodeToString(result), nil
}

// DecryptDESCBC 解密 EncryptDESCBC 的输出。
func DecryptDESCBC(encoded string, key []byte) ([]byte, error) {
	if len(key) != 8 {
		return nil, errors.New("DES key must be exactly 8 bytes")
	}

	raw, err := base64.StdEncoding.DecodeString(encoded)
	if err != nil {
		return nil, err
	}

	block, err := des.NewCipher(key)
	if err != nil {
		return nil, err
	}

	blockSize := block.BlockSize()
	if len(raw) < blockSize*2 || len(raw)%blockSize != 0 {
		return nil, errors.New("invalid ciphertext length")
	}

	iv := raw[:blockSize]
	ciphertext := raw[blockSize:]

	mode := cipher.NewCBCDecrypter(block, iv)
	plaintext := make([]byte, len(ciphertext))
	mode.CryptBlocks(plaintext, ciphertext)

	// 去除 PKCS#7 填充
	padding := int(plaintext[len(plaintext)-1])
	if padding < 1 || padding > blockSize {
		return nil, errors.New("invalid PKCS#7 padding")
	}
	return plaintext[:len(plaintext)-padding], nil
}

Go 标准库的 crypto/des 包仅实现单 DES（8 字节密钥）。如需 3DES，使用 des.NewTripleDESCipher 并传入 24 字节密钥。

常见错误配置

1. 新系统使用单 DES：56 位密钥空间已可被暴力破解。应使用 AES-256-GCM。
2. 3DES 视为长期方案：3DES 的 64 位分组在大量数据下存在碰撞风险，且性能远差于 AES。应计划迁移。
3. DES-ECB 加密多块数据：即便在遗留系统中也应至少使用 CBC 模式。
4. 密钥硬编码：8 字节的 DES 密钥仅 8 个字符，极易被扫描工具发现。密钥应从环境变量或 KMS 获取。
5. 忽略完整性校验：DES-CBC 不提供认证。若无法避免使用 DES，至少应叠加 HMAC-SHA256。
6. 弱密钥与半弱密钥：DES 存在 4 个弱密钥和 12 个半弱密钥（如全 0、全 1 等），使用它们会显著削弱安全性。Go 的 des.NewCipher 不会自动检测弱密钥。

从 DES/3DES 迁移到 AES 的建议

• 存量数据迁移：读取时按旧算法（DES/3DES）解密，写入时使用 AES-256-GCM 加密，记录迁移进度。
• 对端协议兼容：若对接方仅支持 3DES-CBC，需在过渡期保留 3DES 解密能力，同时推动对端升级。
• 密钥管理升级：从 8 字节（DES）或 24 字节（3DES）迁移到 32 字节 AES-256 密钥，一并引入密钥版本号机制。
• 合规对齐：PCI DSS 3.1 起已禁止新部署使用 SSL/早期 TLS，并限制 3DES；FIPS 140-3 已将 3DES 标记为 deprecated。新系统如需合规认证，必须使用 AES。

小结

DES 是现代密码学的里程碑，但受限于 56 位有效密钥和 64 位分组，在算力增长的当下已不具备足够的安全性。3DES 作为临时补救方案延长了 DES 的使用周期，但其性能与安全性均远逊于 AES。

实践结论：新系统使用 AES-256-GCM；迁移存量时自 DES → AES 方向改造；仅在对接方明确指定且无法协商时保留 3DES 解密路径。DES 的知识值得学习，但不应再用于保护真实数据。