加密与认证的本质区别：从核心原理到实战应用

1. 项目概述：从“看不懂”到“信得过”的鸿沟

“加密”和“认证”，这两个词在信息安全领域就像一对形影不离的孪生兄弟，经常被同时提及，却又常常被混为一谈。很多刚入行的朋友，甚至一些有经验的开发者，在设计和实现系统时，也容易在这两者的边界上犯迷糊。比如，给一个API接口加上了HTTPS，就以为万事大吉，数据既安全又可信了；或者，用MD5给文件生成了一个“指纹”，就认为文件内容绝对没有被篡改过。这些理解上的偏差，往往就是安全漏洞的温床。

我自己在十多年的开发和架构师生涯里，见过太多因为混淆两者而引发的“事故”：有的系统用AES加密了用户密码，却在传输过程中被中间人篡改了其他关键业务字段而浑然不觉；有的应用虽然做了签名认证，确保请求来自合法客户端，但敏感的用户聊天记录却以明文形式在网络上“裸奔”。这些问题的根源，就在于没有透彻理解加密和认证各自要解决的核心矛盾。

所以，今天我想彻底掰开揉碎地聊聊这个话题。那句标题里的总结非常精辟：加密解决的是“数据不被看懂”的问题，而认证解决的是“数据来源可信、内容未被篡改”的问题。这句话就是我们的“北极星”，接下来的所有讨论都将围绕这个核心区别展开。我会用大量实际的场景、代码片段和踩坑经验，带你弄清楚什么时候该用加密，什么时候该用认证，以及如何正确地结合使用它们，构建真正坚固的安全防线。无论你是前端、后端、运维还是安全工程师，理解这个本质区别，都是你设计可靠系统不可或缺的一课。

2. 核心概念拆解：目标、手段与对抗的敌人

要理解区别，我们得先回到最根本的问题：它们各自的目标是什么？面对什么样的“敌人”？又使用了什么样的“武器”？

2.1 加密：为隐私穿上“隐身衣”

加密的终极目标是保密性。它的核心诉求是：即使数据被不该看的人截获了，他也看不懂里面到底是什么。这就像你写日记用了一种只有你自己懂的暗号，就算日记本被人偷了，里面的内容对他人来说也只是一堆天书。

• 对抗的敌人：窃听者。这个敌人关心的是“内容是什么”。他可能潜伏在网络链路中，也可能窃取了你的数据库备份。
• 核心手段：数学变换。通过加密算法（如AES, RSA）和密钥，将可读的明文转化为不可读的密文。没有密钥，从密文反推明文在计算上是不可行的。
• 一个生活化类比：你想给朋友寄一封情书，但又怕被父母截获看到。于是你们约定使用一种移位密码（比如每个字母向后移3位）。这样，即使信被拆开，看到的也是“Khoor Zruog!”这样的乱码，只有你的朋友知道用反向移位规则才能还原成“Hello World!”。这里的“移位规则”和“偏移量3”就共同构成了一个简单的加密密钥。

在实际工程中，加密无处不在。当你使用HTTPS访问网站时，浏览器和服务器之间的通信内容就被TLS协议加密了；当你用BitLocker或FileVault加密整个磁盘时，存储在硬盘上的所有文件都以密文形式存在；甚至你保存在数据库里的用户密码（当然，应该是加盐哈希后的，这本质上是单向加密），也是为了防范数据库泄露后密码被直接盗用。

注意：这里必须提一个常见的误区。很多人认为“加密了就等于安全了”。这是大错特错的。加密只解决了保密性问题。如果加密算法本身有漏洞（如弱随机数生成器导致密钥可预测），或者密钥管理不当（如硬编码在客户端代码里），加密形同虚设。著名的“心脏滴血”漏洞，就是因为TLS协议实现中的一处缺陷，可能导致加密内容被窃取。

2.2 认证：为数据盖上“可信印章”

认证的终极目标是完整性和真实性。它关心的是：这份数据是谁发的？在传输或存储过程中有没有被掉包或修改过？它不关心数据内容是否被看见，只关心数据本身是否“原汁原味”且来源可靠。

• 对抗的敌人：篡改者和伪造者。这个敌人可能不关心你的聊天内容，但他想把你转账的“100元”改成“10000元”，或者伪装成系统管理员给你发送一条重置密码的指令。
• 核心手段：摘要与签名。通常使用散列函数（如SHA-256, SM3）生成数据的“指纹”（消息摘要），然后通过密钥对这个指纹进行签名（如HMAC），或使用非对称加密的私钥进行签名（数字签名）。接收方通过验证签名来判断数据和来源是否可信。
• 一个生活化类比：你从网上下载了一个大型软件安装包（如Linux系统镜像）。官网除了提供下载链接，还会提供一个由SHA-256算法计算出的、很长的一串哈希值（如a1b2c3...）。下载完成后，你用自己的工具对本地文件计算一次SHA-256，如果结果和官网公布的一模一样，你就可以99.999%地确信这个文件在下载过程中没有发生任何比特位的错误或被恶意篡改。这个哈希值，就是一种最简单的完整性认证（虽然未涉及来源真实性）。

在工程实践中，认证同样广泛。API请求常用的签名算法（如AWS的Signature Version 4），就是认证的典型应用：客户端用密钥对请求参数、时间戳等生成一个签名，附在请求头中；服务端用同样的密钥和规则验证签名，如果一致，就证明这个请求确实来自持有合法密钥的客户端，且参数未被篡改。软件包管理器（如npm, pip）检查包的完整性，也是基于认证机制。

2.3 对比表格：一目了然的本质差异

为了更清晰地展示，我把它们的核心差异总结成下表：

理解这张表，你就能在大多数场景下做出正确判断。当你的需求是“别让人看见”时，优先考虑加密；当你的需求是“确保这东西没被动手脚且是谁谁谁发的”时，优先考虑认证。

3. 技术原理深潜：算法、模式与组合拳

知道了“是什么”和“为什么”，我们还得深入“怎么做”的层面。这一节，我们会钻进几个关键技术的内部，看看它们是如何运作的，以及为什么有些组合方式是安全的，有些则是危险的。

3.1 加密的核心：对称与非对称的江湖

加密算法主要分为两大门派：对称加密和非对称加密。

对称加密好比你用同一把钥匙锁门和开门。加密和解密使用同一个密钥。它的优点是速度快，适合加密大量数据。

• 典型算法：AES (Advanced Encryption Standard)。这是目前最主流、最安全的对称加密算法，密钥长度可以是128、192或256位。你提到的rust aes cbc加密、aes加密都是它的具体实现或模式。
• 关键概念：工作模式。光有AES算法还不够，如何用它对一段长数据进行加密？这就需要工作模式，如ECB, CBC, CTR, GCM等。
  • ECB模式：最简单，将数据分块独立加密。致命缺点：相同的明文块会产生相同的密文块，无法隐藏数据模式。绝对不要用于需要保密性的场景。
  • CBC模式：引入初始化向量，每个明文块先与前一个密文块异或后再加密，解决了ECB的模式问题。这是过去非常常用的模式。
  • GCM模式：这是当今的明星。它不仅是加密模式，更是一种认证加密模式。它在CTR模式（一种高效加密模式）的基础上，同时生成一个认证标签（GMAC），一举解决了保密性和认证（完整性）两个问题。无线网络radius认证接入中使用的安全协议，就很可能用到基于GCM的加密套件。

非对称加密则像信箱和钥匙。公钥是公开的信箱，谁都可以往里投递加密的信件；私钥是只有你有的钥匙，用来打开信箱取出信件。加密用公钥，解密用私钥。它的优点是解决了密钥分发问题，但速度慢，通常只用于加密少量数据（如一个会话密钥）。

• 典型算法：RSA, ECC (椭圆曲线加密)。vue2 sm2加密中的SM2，就是中国商用密码体系中的椭圆曲线非对称加密算法。
• 核心应用：密钥交换（如TLS握手过程中的RSA或ECDHE）和数字签名（用私钥签名，用公钥验证）。

实操心得：在实际系统中，我们通常采用混合加密体系。用非对称加密安全地传递一个随机的对称会话密钥，然后用这个对称密钥去加密实际要传输的大量业务数据。HTTPS的TLS协议正是这么做的。直接使用RSA加密大文件是极其低效且不推荐的做法。

3.2 认证的基石：散列、MAC与数字签名

认证技术栈也有几个层次，从简单到复杂。

散列函数：它是一个单向的、不可逆的“指纹提取器”。输入任意长度的数据，输出一个固定长度的散列值（如SHA-256输出256位）。好的散列函数具有抗碰撞性（极难找到两个不同的输入产生相同的输出）。

• 用途：校验数据完整性（如下载文件校验）、密码存储（加盐后哈希，而非加密！）。
• 注意：单纯的散列值（如一个公开的SHA-256值）只能验证完整性，不能验证真实性。因为攻击者可以同时篡改文件和其对应的散列值。sm3在线加密中的SM3，就是国产的散列函数标准。

消息认证码：这是散列函数的升级版，引入了密钥。HMAC是最常见的MAC构造方式。HMAC-SHA256(key, message)表示用密钥key对消息message计算MAC值。

• 核心：只有拥有相同密钥的双方，才能生成和验证有效的MAC。因此，它同时提供了完整性和真实性（证明消息来自拥有密钥的一方）。
• 应用：API签名、消息队列中消息的防篡改。你搜索的oauth2.0认证原理中，客户端持有client_secret，在请求时生成签名，服务端用同样的secret验证，这就是MAC思想的一种应用。

数字签名：这是非对称加密技术在认证领域的应用。发送方用私钥对数据的散列值进行加密，这个加密结果就是签名。接收方用发送方的公钥解密签名，得到散列值，再与自己计算的数据散列值对比。

• 优势：解决了密钥分发问题。公钥可以公开，任何人都可以验证签名，但只有私钥持有者才能生成签名。这提供了不可否认性（发送方不能抵赖他签过名）。
• 应用：SSL/TLS证书、软件发行包签名、区块链交易。ibe加密原理（基于身份的加密）是一种特殊的非对称加密体系，其签名机制也独具特色。

3.3 危险的组合与正确的姿势：认识认证加密

历史上，开发者们常常需要手动组合加密和认证，比如先AES加密，再HMAC签名。但这充满了陷阱，认证加密这个概念正是为此而生。维基百科的词条清晰地指出了这一点：“安全地将保密模式与认证模式组合可能是容易出错和困难的”。

为什么容易出错？主要有三种组合方式：

1. Encrypt-and-MAC：分别对明文加密和生成MAC，将密文和MAC一起发送。问题在于，MAC是基于明文的，可能泄露明文信息。SSH早期协议在某些模式下使用此方式，现已不推荐。
2. MAC-then-Encrypt：先对明文生成MAC，然后将“明文+MAC”一起加密。SSL/TLS历史上用过这种方式。它最大的风险在于“填充预言攻击”。接收方解密后，如果发现填充错误或MAC校验失败，可能会返回不同的错误信息，攻击者利用这些细微的差异反馈，可能逐步推算出密钥或明文。这就是著名的Lucky Thirteen attack等攻击的原理。
3. Encrypt-then-MAC：先加密得到密文，然后对密文生成MAC，发送“密文+MAC”。这是目前被证明最安全的一种组合方式。接收方先验证MAC，如果MAC无效，直接拒绝，无需解密。这可以有效抵御填充预言攻击。IPsec协议就采用这种方式。

而现代更优的选择是使用原生支持认证加密的模式，如AES-GCM、ChaCha20-Poly1305。这些模式在算法设计层面就将加密和认证无缝融合，性能更好，且更不易误用。你在NIST标准中看到的CCM、EAX、GCM都属于此类。认证加密维基百科词条中提到的OCB模式也是其中一种，但它涉及专利问题，使用不如GCM广泛。

踩坑记录：我曾维护过一个旧系统，它使用“AES-CBC加密 + 在HTTP头里传一个MD5哈希值”的方式来保证数据安全。这属于典型的、不安全的自制“Encrypt-and-MAC”模式。首先，MD5已不抗碰撞，不安全；其次，哈希值在外部传输，与密文没有密钥绑定，攻击者完全可以替换掉整个数据包和哈希值。我们后来将其整体迁移到了TLS 1.2+（使用AES-GCM套件），并重构了应用层的签名逻辑，才消除了隐患。

4. 实战场景剖析：从理论到代码的跨越

理论说得再多，不如一行代码。这一部分，我们通过几个最常见的实战场景，看看如何正确应用加密和认证。

4.1 场景一：设计一个安全的API接口

这是后端开发者最常遇到的场景。假设我们有一个转账接口POST /api/transfer。

错误做法：

1. 只用HTTPS（传输层加密），认为万事大吉。但HTTPS主要防护中间人窃听和篡改。如果攻击者通过某种方式获取了你的API调用方式（比如反编译了客户端），他可以直接伪造请求。HTTPS不验证业务请求的合法性。
2. 在请求参数里明文传递用户ID和金额，然后加一个sign参数，这个sign是所有参数按字母排序后拼接再MD5。这非常脆弱，因为MD5可被快速碰撞，且参数拼接方式若被知悉，极易被伪造。

正确做法（采用认证确保请求可信）： 我们使用HMAC-SHA256作为签名方法，采用“签名参数放在最后计算”的常见安全实践。

import hmac import hashlib import time import json def generate_api_signature(secret_key, http_method, api_path, params, timestamp): """ 生成API请求签名 :param secret_key: 分配给客户端的密钥 :param http_method: GET/POST等 :param api_path: 如 /api/transfer :param params: 字典，请求参数（GET的Query或POST的Body） :param timestamp: 时间戳，用于防重放 :return: 签名字符串 """ # 1. 参数排序并序列化。注意：要排除签名参数本身 sorted_params = sorted(params.items(), key=lambda x: x[0]) # 将参数转换为 `key1=value1&key2=value2` 格式，注意value需要做URL编码 param_str = '&'.join([f"{k}={v}" for k, v in sorted_params]) # 2. 构造待签名字符串。常用格式：方法 + 路径 + 参数串 + 时间戳 string_to_sign = f"{http_method}\n{api_path}\n{param_str}\n{timestamp}" # 3. 使用HMAC-SHA256计算签名 signature = hmac.new( secret_key.encode('utf-8'), string_to_sign.encode('utf-8'), hashlib.sha256 ).hexdigest() # 输出16进制字符串 return signature # 客户端调用示例 secret_key = "your_client_secret_here" api_path = "/api/transfer" params = { "from_account": "user123", "to_account": "user456", "amount": "100.00", "currency": "CNY" } timestamp = int(time.time()) # 当前时间戳 signature = generate_api_signature(secret_key, "POST", api_path, params, timestamp) # 最终请求头可能包含 headers = { "X-Client-Key": "your_client_id", "X-Timestamp": str(timestamp), "X-Signature": signature } # 然后以JSON格式发送params，并附上这些headers

服务端收到请求后，用同样的算法和存储的secret_key重新计算签名，并与请求头中的X-Signature对比。同时，必须校验X-Timestamp与服务器当前时间差是否在合理窗口内（如±5分钟），以防止签名被截获后重放攻击。

这里认证解决了什么问题？

• 真实性：签名证明了请求来自持有合法secret_key的客户端。
• 完整性：任何对请求方法、路径、参数的篡改，都会导致签名验证失败。
• 防重放：时间戳机制使得截获的旧请求无法被重复使用。

加密的角色在哪？在整个过程中，HTTPS（TLS）提供了传输层的加密，确保了secret_key不会在初次协商时被窃听，也保护了请求和响应体（包括params和signature）在传输过程中不被窥探。这是典型的“传输加密 + 应用层认证”组合。

4.2 场景二：安全地存储用户密码

这几乎是每个系统的必备功能。核心原则是：绝对不要明文存储密码，也不要使用可逆的加密存储密码。

错误做法：

1. 明文存储。数据库泄露即全军覆没。
2. 使用对称加密（如AES）存储。密钥管理成为单点故障，一旦密钥泄露，所有密码可被解密。
3. 使用简单的、无盐的MD5或SHA-1哈希。彩虹表攻击可以快速破解常见密码。

正确做法（利用哈希函数的单向性进行“认证”）： 我们存储的其实不是密码，而是密码的“凭证”。验证时，是比对“凭证”是否匹配。

import hashlib import os import binascii def hash_password(password): """使用加盐的PBKDF2算法哈希密码""" # 1. 生成一个随机的盐 salt = os.urandom(16) # 16字节的随机盐 # 2. 使用PBKDF2（一种密钥派生函数，也是故意慢的哈希）进行哈希 # 这里使用SHA-256作为底层哈希函数，迭代10万次 key = hashlib.pbkdf2_hmac('sha256', password.encode('utf-8'), salt, 100000) # 3. 存储时，将盐和哈希后的密钥一起存储，通常用特定格式，如 `算法$迭代次数$盐$哈希值` stored = f"pbkdf2_sha256$100000${binascii.hexlify(salt).decode()}${binascii.hexlify(key).decode()}" return stored def verify_password(stored_password, provided_password): """验证提供的密码是否与存储的哈希值匹配""" # 1. 从存储的字符串中解析出算法、迭代次数、盐和哈希值 parts = stored_password.split('$') if len(parts) != 4: return False _, iterations, salt_hex, key_hex = parts salt = binascii.unhexlify(salt_hex) stored_key = binascii.unhexlify(key_hex) iterations = int(iterations) # 2. 用同样的参数对提供的密码进行计算 new_key = hashlib.pbkdf2_hmac('sha256', provided_password.encode('utf-8'), salt, iterations) # 3. 使用恒定时间比较函数，防止时序攻击 return hmac.compare_digest(new_key, stored_key) # 使用示例 user_input_password = "MySuperSecretPassword123!" hashed = hash_password(user_input_password) print(f"存储的哈希值: {hashed}") # 模拟登录验证 is_correct = verify_password(hashed, "MySuperSecretPassword123!") print(f"密码正确吗？ {is_correct}") # 应输出 True is_correct = verify_password(hashed, "WrongPassword") print(f"密码正确吗？ {is_correct}") # 应输出 False

这里加密和认证分别是什么角色？

• 这个过程没有使用加密！因为加密是可逆的，而我们需要的是不可逆的变换。
• 我们使用的是密码学哈希函数（SHA-256）和密钥派生函数（PBKDF2）。加盐是为了防止彩虹表攻击，高迭代次数是为了增加暴力破解的成本。当用户登录时，系统用同样的盐和参数计算输入密码的哈希值，与存储的哈希值进行比对。这本质上是一个认证过程：系统在验证用户提供的“密码凭证”是否与当初注册时生成的“凭证”匹配。它证明了用户知道密码，而不需要系统也知道密码。

4.3 场景三：端到端加密聊天应用

在这个场景下，我们要求即使服务提供商也无法看到聊天内容。这需要结合非对称加密、对称加密和认证。

简化流程如下：

1. 密钥交换：用户A和B在首次通信时，交换各自的非对称加密公钥（例如，使用RSA或ECC密钥对）。这可以通过服务器中转，因为公钥本来就是可以公开的。
2. 会话密钥协商：每次发起新会话时，由一方（如A）生成一个随机的对称加密会话密钥（如一个256位的AES密钥）。A用B的公钥加密这个会话密钥，发送给B。只有B能用自己的私钥解密获得会话密钥。现在A和B共享了一个秘密的会话密钥。这个过程利用了非对称加密来安全地传递对称密钥。
3. 消息加密与认证：
   • A要发送消息“Hello”。A使用AES-GCM模式，用会话密钥加密“Hello”，得到密文C1，同时GCM模式会自动生成一个认证标签T1。
   • A将C1和T1发送给B。
   • B收到后，使用相同的会话密钥和AES-GCM模式解密C1，并同时验证认证标签T1。
   • 如果验证通过，则解密出的明文就是可信的“Hello”；如果失败，则说明消息在传输中被篡改或来源有问题，B会丢弃该消息。

在这个流程中：

• 非对称加密用于安全地交换对称会话密钥（解决密钥分发问题）。
• 对称加密（AES-GCM）用于高效地加密实际聊天消息（解决大量数据的保密性问题）。
• 认证加密模式（GCM）在加密的同时，提供了消息的完整性和真实性认证，确保消息来自对方且未被篡改。

这便是一个完整的、结合了加密与认证的实战案例。flutter 使用java后端的红钥加密、ibe加密原理等搜索词，都可能是在探索类似场景下的具体技术选型或算法实现。

5. 常见误区、问题排查与选型指南

即使理解了原理，在实际操作中仍然会碰到各种坑。这一节，我结合自己的经验，整理了一些高频误区和问题排查思路。

5.1 十大经典误区与避坑指南

1. 误区：HTTPS = 绝对安全

   • 正解：HTTPS（TLS）提供了传输层的加密和服务器身份认证（通过证书），是基础安全设施。但它不验证客户端身份（除非使用双向TLS），也不验证业务逻辑的合法性。应用层签名/认证仍是必须的。

2. 误区：MD5/SHA-1可以用于密码加密

   • 正解：MD5和SHA-1是哈希函数，不是加密算法。它们用于密码存储时，必须加盐并使用慢哈希函数（如PBKDF2, bcrypt, scrypt, Argon2），以抵御彩虹表和暴力破解。

3. 误区：我们自己设计了一套“独创”的加密算法

   • 正解：绝对不要自己发明加密算法。密码学领域有句名言：“任何业余爱好者都能设计出一个自己无法破解的密码系统”。使用经过全球密码学家多年公开审视和攻击测试的标准算法（如AES, RSA, ECC, SHA-256, ChaCha20-Poly1305）。

4. 误区：加密密钥硬编码在代码或配置文件中就很安全

   • 正解：密钥管理是加密系统的生命线。硬编码的密钥极易在代码仓库泄露、反编译中暴露。应使用专业的密钥管理服务，或至少从环境变量、安全的密钥仓库中动态加载。

5. 误区：用了AES就高枕无忧了

   • 正解：AES是算法，还需要正确的模式和参数。避免使用ECB模式；使用CBC模式时必须使用随机且不可预测的IV（初始化向量），并确保IV随密文一起传输；更推荐使用GCM等认证加密模式。rust aes cbc加密的实践中，必须注意IV的生成和传递。

6. 误区：签名/认证不需要时间戳或随机数

   • 正解：缺少防重放机制是API安全常见漏洞。攻击者可以截获一个有效的请求包，重复发送。必须在签名参数中加入时间戳或随机数，服务端校验其有效性。

7. 误区：压缩包加密（ZIP密码）很安全

   • 正解：传统的ZIP加密（ZipCrypto）非常脆弱，容易被破解。即使使用AES加密的ZIP，其安全性也依赖于密码强度。对于敏感数据，应使用专门的文件加密工具（如GPG）或全盘加密。

8. 误区：认证签名时，只对部分参数签名

   • 正解：签名应覆盖所有可被客户端篡改的参数，包括URL路径、查询参数、请求体，甚至重要的请求头（如User-Agent在某些场景下）。任何未被签名的参数都可能成为攻击入口。

9. 误区：证书错误（如自签名证书）点一下“继续访问”就行

   • 正解：浏览器或客户端提示证书错误，通常意味着身份认证链断裂（可能是中间人攻击！）。在生产环境中，必须使用受信任的证书颁发机构签发的证书。开发环境可以使用自签名证书，但应在代码或系统中明确信任它，而不是盲目跳过。

10. 误区：混淆了“编码”与“加密”

    • 正解：Base64、URL编码等只是编码，目的是为了在不同系统间安全地传输二进制数据，没有任何保密性。它们可以轻易被解码还原。不要把编码当成加密使用。

5.2 问题排查清单：当加密或认证失败时

当你遇到诸如“解密失败”、“签名无效”、“证书错误”等问题时，可以按以下清单排查：

5.3 技术选型快速参考指南

面对众多算法和模式，如何选择？这里有一个简单的决策树：

1. 目标是什么？

   • 只想确保数据没被改过，且来源可信？-> 选择认证。使用HMAC-SHA256（对称密钥）或Ed25519数字签名（非对称密钥）。
   • 只想确保数据内容保密，不怕被改？(几乎不存在这种单一需求) -> 选择加密。使用AES-256-GCM或ChaCha20-Poly1305（它们实际上也提供了认证）。
   • 既要保密，又要防篡改和验证来源？-> 选择认证加密。直接使用AES-256-GCM或ChaCha20-Poly1305。或者，采用“Encrypt-then-MAC”组合（例如，用AES-CBC加密，然后用HMAC-SHA256对密文做MAC）。

2. 密钥如何管理？

   • 双方可以安全地共享一个密钥？ -> 使用对称算法（AES, HMAC）。
   • 需要公开分发验证能力，或解决密钥分发问题？ -> 使用非对称算法（RSA/ECC用于加密或签名）。

3. 性能要求？

   • 加密/解密大量数据 ->对称加密远快于非对称加密。
   • 仅签名/验证 ->椭圆曲线签名（如Ed25519）比RSA签名更快更安全。

4. 具体推荐（2024年及以后）：

   • 传输安全：无脑选择TLS 1.3。它禁用了不安全的算法，握手更快，默认使用前向安全的密钥交换。
   • 数据加密：AES-256-GCM或ChaCha20-Poly1305。后者在移动设备等没有AES硬件加速的环境下性能更好。
   • 密码存储：Argon2id>scrypt>bcrypt>PBKDF2。根据你的平台支持情况选择。
   • API签名：HMAC-SHA256（对称，需安全分发密钥）或Ed25519（非对称，公钥可公开）。
   • 软件/固件签名：ECDSA with P-256或Ed25519。固件加密往往也伴随着签名验证。

记住，没有银弹。最好的方案是根据你的具体威胁模型、性能预算和运维复杂度来权衡。但只要你牢牢抓住“加密防窥视，认证防篡改和伪造”这个本质，你就已经走在了正确的道路上。安全是一个过程，而不是一个产品，持续学习、谨慎实践、定期审计，才能让你的系统在攻防对抗中立于不败之地。