Kerberos票据加密必须使用对称算法，核心依据是协议对密钥共享与高效加解密的刚性需求；DES和AES是主流选择，非对称算法及哈希函数不参与票据主体加密。
kerberos 认证中票据加密算法的选择，核心依据是协议对对称加密的刚性需求，而非单纯追求“最新”或“最强”。它必须满足高效加解密、密钥可共享、支持时间戳防重放等机制，同时与 kdc 和客户端/服务端的密钥派生逻辑严格匹配。
符合 Kerberos 协议架构的对称性要求
Kerberos 依赖可信第三方（KDC）分发会话密钥，所有票据（TGT、服务票据）和认证器（Authenticator）都需用双方共享的密钥加密。这决定了只能选用对称算法：
- DES 是原始设计标准，因其加解密速度快、实现简单，适配早期网络环境和轻量级票据操作；
- AES（如 AES-128、AES-256）在 Kerberos v5 中作为可选扩展引入，安全性更高，但需客户端、服务端和 KDC 同步支持相同算法套件；
- RSA、ElGamal、DSA 等非对称算法不参与票据主体加密，仅可能用于跨域密钥交换等辅助场景，不属于票据加密范畴。
与密钥派生和密码策略兼容
用户口令并不直接作为加密密钥，而是通过特定字符串变换（如 RFC 3961 定义的 string2key）生成 DES 或 AES 密钥。因此算法选择必须：
- 支持标准 key derivation 函数（如 des-cbc-md5、aes128-cts-hmac-sha1-96）；
- 能正确处理不同长度口令映射到固定长度密钥（例如 DES 要求 8 字节密钥，AES-128 要求 16 字节）；
- 与域策略中的密码复杂度、过期周期、历史记录等联动——若强制使用 AES，而用户仍用弱口令，整体安全性并未提升。
兼顾向后兼容与实际部署约束
生产环境中算法选择常受现实条件制约：
- 老旧系统（如某些 Windows Server 2003 域成员）仅支持 DES 或 RC4（已弃用），强行启用 AES 可能导致认证失败；
- 混合环境需在 KDC 上配置多算法优先级（如 krb5.conf 中的 default_tgs_enctypes），确保客户端能协商出双方都支持的算法；
- 禁用 DES 并非一劳永逸：若未同步清理旧密钥版本（如 AD 中残留的 DES key），仍可能被降级利用，需结合策略彻底移除。
不依赖哈希算法完成加密功能
MD5、SHA-1 等哈希函数在 Kerberos 中仅用于完整性校验（如 HMAC-SHA1）、密钥派生中间步骤或票据校验和，它们不可逆、无密钥，不能替代加密算法：
- 选 MD5 或 SHA-1 作“加密算法”属于概念混淆，题干若出现此类选项，可直接排除；
- 现代 Kerberos 实现中，HMAC 类型（如 hmac-sha256）用于签名票据，但加密层仍由 AES 或 DES 承担。
