对称加密与非对称加密|HTTP协议篇
# 对称加密与非对称加密
30 秒速记
- 在
HTTPS和TLS中，密钥表现为一段二进制数字。 - 密钥长度通常以
bit标注，不以byte标注，换算关系是8 bit = 1 byte。 - 例如
128 bit对应16 byte，1024 bit对应128 byte。 - 按加密与解密阶段如何使用密钥，可以把加密体系分成对称加密和非对称加密。
- 密钥位数只是长度指标；材料没有给出不同算法之间按位数直接比较安全性的依据。
对称加密和非对称加密的区别，本质上是加密、解密阶段使用的密钥关系不同。 对称加密由双方共享同一把密钥，非对称加密则使用存在数学关联的公钥和私钥。密钥是算法接收的二进制输入，通常以 bit 衡量，例如 128 bit 等于 16 byte。不过位数只能表示长度，不能跨算法直接比较安全性；检查配置时还要结合算法、参数和密钥来源。
由于 HTTPS、TLS 都运行在计算机上，所以“密钥”就是一长串的数字，但约定俗成的度量单位是“位”（bit），而不是“字节”（byte）。比如，说密钥长度是 128，就是 16 字节的二进制串，密钥长度 1024，就是 128 字节的二进制串。
按照密钥的使用方式，加密可以分为两大类：对称加密和非对称加密。
原理拆解： 密钥本质上是算法接收的一段二进制输入，密钥空间大小通常写成 2^n，其中 n 就是以 bit 表示的密钥长度。128 bit 等于 16 byte，但“长度相同”只说明二进制位数相同，不能推出不同算法具有相同安全性。算法结构、有效密钥空间、已知攻击方式和参数选择都会影响最终强度。
具体例子： 对称加密中，发送方和接收方持有同一个秘密密钥：发送方用它把明文变为密文，接收方再用同一密钥恢复明文。非对称加密则生成存在数学关联的一对密钥，例如公开公钥、严格保存私钥；用公钥完成的加密只能由对应私钥解开。这里的“对称”和“非对称”描述的是加解密阶段的密钥关系，而不是密文外观。
边界与反例： 不能因为 RSA 密钥常见长度大于 AES，就认定 RSA 更安全。两者建立在不同数学问题和攻击模型上，位数没有横向等价关系。密钥也不是密码字符串的同义词：用户口令通常要经过专门的密钥派生过程，才能成为适合算法使用的固定长度密钥。
工程验证： 检查系统配置时，应同时记录算法名称、模式或参数、密钥长度以及密钥来源，而不是只看一个位数。还可以直接核对密钥材料的字节数，例如长度为 16 字节的随机值对应 128 bit；若算法要求固定长度而输入不匹配，可靠的加密库应拒绝执行，而不应由业务代码自行截断或补零。
面试官追问
追问 1配置中心把 keyLength: 128 解释成 128 byte，生成的密钥文件也按这个长度校验，你会怎样指出问题？
密码学语境中的 128 通常表示 128 bit，也就是 16 byte，把它直接当字节会放大八倍。修正前仍要核对具体库的参数单位和算法要求，不能只凭字段名截断已有密钥或自行补零。
追问 2安全评审只记录了“密钥长度 256 bit”，却没有算法名、模式和密钥来源，这份记录为什么不足以判断配置？
位数只描述密钥二进制输入的长度，无法单独说明采用了哪种算法以及最终安全强度。应同时记录算法、模式或参数、密钥长度和密钥来源；不同算法还受结构、有效密钥空间、已知攻击和参数选择影响。
追问 3团队看到 RSA 1024 bit 的数字大于 AES 256 bit，因此决定前者一定更安全，你会接受这个选型依据吗？
不会，RSA 与 AES 建立在不同的数学问题和攻击模型上，密钥位数不能横向等价比较。选型需要结合算法类别、已知攻击与参数，而材料没有提供把两者折算成统一安全强度的规则。
追问 4接口接收到一个长度不符的密钥，业务代码准备截断或补零后继续加密，以避免线上请求失败，你会怎么处理？
不应由业务代码自行截断或补零，这会改变密钥材料并掩盖配置错误。应先按算法要求核对字节数，例如 16 byte 对应 128 bit，可靠的加密库在固定长度不匹配时应拒绝执行；代价是请求失败，但比静默使用错误密钥更可控。
追问 5登录系统把用户输入的密码字符串直接标注为“对称密钥”，并据此在客户端和服务端复用，你会怎样评审？
用户口令不是适合算法直接使用的固定长度密钥，通常需要专门的密钥派生过程才能形成密钥材料。还要先明确方案是双方共享同一秘密，还是使用数学关联的公私钥对；仅凭字符串外观无法完成对称与非对称分类。
追问 6架构师要求为通信方案划分对称与非对称两类，代码中最应该检查哪种密钥关系？
应检查加密和解密阶段如何使用密钥：双方使用同一秘密密钥属于对称关系，公开公钥并由对应私钥解密属于非对称关系。分类依据不是密文外观、文件大小或协议名称，具体算法的安全性仍需结合参数单独判断。
# 对称加密
30 秒速记
- 对称加密使用同一把密钥完成加密和解密，通信双方都必须持有它。
- 密文被窃听时，没有密钥的一方无法直接还原明文，因此机密性依赖密钥不泄露。
- 它的关键边界是密钥安全：一旦共享密钥暴露，通信内容的保密基础也随之失效。
- 按材料列举的算法范围，
RC4、DES、3DES已被视为不安全，常用选择主要是AES和ChaCha20。 AES支持128、192、256 bit密钥，安全性与性能均较好，并可受益于硬件优化。ChaCha20固定使用256 bit密钥，纯软件性能突出；在具备AES硬件加速的平台上，其性能优势可能不再明显。
对称加密就是通信双方使用同一把密钥加密和解密，机密性直接依赖这把密钥不泄露。 窃听者即使拿到密文，没有密钥也无法直接还原明文；反过来，密钥一旦暴露，保密基础也就失效了。材料列出的常用选择主要是 AES 和 ChaCha20，前者支持 128、192、256 bit 密钥并可利用硬件优化，后者固定为 256 bit 且纯软件性能较好。实际选择要看运行平台，具备 AES 硬件加速时，ChaCha20 的性能优势可能并不明显。
“对称加密”很好理解，就是指加密和解密时使用的密钥都是同一个，是“对称”的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性。
举个例子，你想要登录某网站，只要事先和它约定好使用一个对称密码，通信过程中传输的全是用密钥加密后的密文，只有你和网站才能解密。黑客即使能够窃听，看到的也只是乱码，因为没有密钥无法解出明文，所以就实现了机密性。
TLS 里有非常多的对称加密算法可供选择，比如 RC4、DES、3DES、AES、ChaCha20 等，但前三种算法都被认为是不安全的，通常都禁止使用，目前常用的只有 AES 和 ChaCha20。
AES 的意思是“高级加密标准”（Advanced Encryption Standard），密钥长度可以是 128、192 或 256。它是 DES 算法的替代者，安全强度很高，性能也很好，而且有的硬件还会做特殊优化，所以非常流行，是应用最广泛的对称加密算法。
ChaCha20 是 Google 设计的另一种加密算法，密钥长度固定为 256 位，纯软件运行性能要超过 AES，曾经在移动客户端上比较流行，但 ARMv8 之后也加入了 AES 硬件优化，所以现在不再具有明显的优势，但仍然算得上是一个不错算法。
面试官追问
追问 1抓包工具显示登录请求是一串不可读字符，开发同学据此认定即使密钥泄露也无法还原明文，你如何反驳？
不可读的密文外观不能抵消密钥泄露风险，对称加密使用同一个密钥完成加密和解密，持有它就具备恢复明文的基础。通信机密性依赖密钥安全；材料未提供额外保护机制，不能假定泄露后的历史密文仍然安全。
追问 2客户端与服务端准备预置同一把对称密钥保护登录数据，上线前你会把工程检查重点放在哪里？
应确认双方使用相同且安全保存的密钥，并选用当前常用的 AES 或 ChaCha20，而不是已被认为不安全的旧算法。只要共享密钥暴露，通信机密性基础就会失效；材料也没有解决密钥如何安全分发的问题。
追问 3旧终端只支持 3DES，业务方要求重新开放该算法以维持登录成功率，安全评审应怎样取舍？
不应把 3DES 重新作为正常可选方案，因为材料将它与 RC4、DES 一同列为不安全并通常禁用。应推动终端升级或调整兼容边界；材料没有提供安全的旧算法兜底方式，不能以可用性诉求证明风险可接受。
追问 4移动端切换到 ChaCha20 后没有出现预期的性能优势，负责人怀疑实现一定有故障，你会先核对什么？
先核对设备硬件环境以及实际启用的算法，不能把“纯软件运行可能更快”理解为所有移动设备上的必然结果。ARMv8 之后存在 AES 硬件优化，ChaCha20 的优势可能不再明显；材料也没有给出固定性能差距。
追问 5同时面向带 AES 硬件优化的新手机和依赖纯软件执行的旧设备，团队要统一选择 AES 或 ChaCha20，你怎么评审？
两者都属于材料认可的常用对称算法，选择应结合目标硬件上的实现条件，而不能宣布某一个在所有设备上更快。AES 支持 128、192、256 bit 密钥且硬件优化广泛，ChaCha20 固定为 256 bit；统一方案可能牺牲部分设备表现。
追问 6有人因 ChaCha20 使用 256 bit 密钥，就认定它必然比 AES-128 更安全并要求全面替换，这个依据充分吗？
依据不充分，密钥位数不能脱离算法结构和攻击模型直接比较安全强度。材料只说明两者都是当前常用算法及各自密钥长度、性能特点，没有给出 ChaCha20 必然优于 AES-128 的结论，选型还需结合硬件与参数。
# 加密分组模式
30 秒速记
- 分组模式规定固定分组的对称算法如何处理任意长度数据，是算法名称之外必须明确的参数。
ECB、CBC、CFB、OFB属于较早的模式；按题干所述的现代TLS语境，通常优先采用带认证能力的方案。AEAD同时提供加密与认证，可保护机密性并检测数据是否被篡改，常见组合包括GCM、CCM和Poly1305。- 算法、密钥长度和模式共同决定具体方案：
AES128-GCM表示使用128位密钥的AES配合GCM，ChaCha20-Poly1305则是另一组算法组合。 - 只看到
AES不能判断完整的安全属性，还需要检查模式、密钥长度以及是否具备认证能力。
加密分组模式决定了对称算法如何用固定长度的密钥处理任意长度的数据。 ECB、CBC 等早期模式存在安全问题，现代 TLS 通常优先选择兼顾加密和认证的 AEAD 方案，例如 GCM。像 AES128-GCM，就是 128 位密钥的 AES 配合 GCM 使用。工程上只看到 AES 还不够，还要确认密钥长度、分组模式以及是否具备认证能力。
