Web IM 聊天信息加密的三种实现方案

在 Chat 组件中使用这些方法。这里要注意，发送前获取公钥，接收后点击解密。为了用户体验，可以加入乐观更新 UI 的逻辑。

后端 Java 实现

后端在此方案中主要负责公钥存储和消息中继，逻辑相对简单。

// User 实体，增加公钥字段
@Entity
@Table(name = "im_users")
@Data
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    
    @Column(columnDefinition = "TEXT")
    private String rsaPublicKey; // PEM 格式
}

// Controller 层示例
@RestController
@RequestMapping("/api/chat")
public class ChatController {
    @Autowired
    private UserRepository userRepository;
    
    @GetMapping("/user/{userId}/public-key")
    public ResponseEntity<?> getUserPublicKey(@PathVariable Long userId) {
        User user = userRepository.findById(userId).orElseThrow();
        if (user.getRsaPublicKey() == null) {
            return ResponseEntity.badRequest().body("User does not have a public key");
        }
        return ResponseEntity.ok().body(Collections.singletonMap("publicKey", user.getRsaPublicKey()));
    }
}

方案一优缺点总结

• 优点：概念简单，符合 E2EE 基本定义。
• 缺点：性能极差（RSA 慢），无前向保密性（私钥泄露则历史消息全暴露），密钥管理复杂（换设备无法同步）。仅适合学习原理，不推荐生产。

方案二：非对称加密 + 数字签名（增强身份验证）

方案一无法确认发送者身份。方案二增加了数字签名，解决身份验证和防篡改问题。

核心流程

1. A 用 B 的公钥加密消息得到密文 C。
2. A 用自己的私钥对消息哈希进行签名 S。
3. 发送 {cipherText: C, signature: S}。
4. B 先用 A 的公钥验证签名，再用自己的私钥解密。

前端增强

在 crypto.js 中补充签名函数：

// 使用私钥对消息进行签名
export function signMessageWithPrivateKey(privateKeyPem, message) {
  try {
    const privateKey = forge.pki.privateKeyFromPem(privateKeyPem);
    const md = forge.md.sha256.create();
    md.update(message, 'utf8');
    const signature = privateKey.sign(md);
    return forge.util.encode64(signature);
  } catch (error) {
    throw new Error('消息签名失败');
  }
}

// 使用公钥验证签名
export function verifySignatureWithPublicKey(publicKeyPem, message, signatureBase64) {
  try {
    const publicKey = forge.pki.publicKeyFromPem(publicKeyPem);
    const md = forge.md.sha256.create();
    md.update(message, 'utf8');
    const signature = forge.util.decode64(signatureBase64);
    return publicKey.verify(md.digest().getBytes(), signature);
  } catch (error) {
    return false;
  }
}

方案二优缺点总结

• 优点：提供了身份验证和不可否认性。
• 缺点：性能进一步下降（两次非对称操作），依然没有前向保密性。

方案三：混合加密系统（推荐生产方案）

这是现代安全通信的标准模型。核心思想是：用非对称加密安全地交换一个临时的对称密钥，然后用这个对称密钥加密实际的消息。

关键特性：前向保密 (Forward Secrecy)

每次会话使用独立的临时密钥。即使长期私钥泄露，攻击者也无法解密过去的通信记录，因为会话密钥早已丢弃。

前端 Vue 实现

我们需要管理会话密钥（Session Key）。

// utils/crypto.js (新增混合加密函数)

// 生成随机的对称密钥和 IV (AES-CBC)
export function generateSymmetricKey() {
  const key = forge.random.getBytesSync(32); // AES-256
  const iv = forge.random.getBytesSync(16);
  return {
    key: forge.util.encode64(key),
    iv: forge.util.encode64(iv)
  };
}

// 使用对称密钥加密消息 (非常快)
export function encryptWithSymmetricKey(keyBase64, ivBase64, message) {
  try {
    const key = forge.util.decode64(keyBase64);
    const iv = forge.util.decode64(ivBase64);
    const cipher = forge.cipher.createCipher('AES-CBC', key);
    cipher.start({ iv: iv });
    cipher.update(forge.util.createBuffer(message, 'utf8'));
    cipher.finish();
    return forge.util.encode64(cipher.output.data);
  } catch (error) {
    throw new Error('消息加密失败');
  }
}

// 使用公钥加密对称密钥（信封）
export function encryptSymmetricKeyWithPublicKey(publicKeyPem, symmetricKeyObj) {
  const keyDataStr = JSON.stringify(symmetricKeyObj);
  return encryptMessageWithPublicKey(publicKeyPem, keyDataStr);
}

在 Vuex Store 中维护会话密钥状态，避免每次发送都重新协商，同时支持过期策略。

高级特性：ECDH 双工协商

更安全的做法是使用 Diffie-Hellman 协议协商共享密钥。双方各自生成临时 ECC 密钥对，交换公钥后计算共享密钥。这样即使长期私钥泄露，过去会话依然安全。这需要引入 libsodium.js 等库来实现。

方案三优缺点总结

• 优点：高性能（对称加密），具备前向保密性，安全性高。
• 缺点：实现复杂度最高，需管理密钥生命周期。

结论：方案三是唯一推荐用于生产环境的方案。

部署与安全最佳实践

密钥安全存储

• 长期私钥：严禁明文存储在 localStorage。建议使用用户密码通过 KDF（如 PBKDF2）派生密钥后再加密存储。
• 会话密钥：可存在内存中，刷新即丢失以增强前向保密；若需持久化，请加密后存入 IndexedDB。

传输安全

• 必须使用 HTTPS 和 WSS 协议。
• 所有 API 调用需严格身份验证（如 JWT）。

常见问题处理

• 无法解密：检查是否换了设备导致私钥丢失，引导用户重新建立会话。
• 签名无效：提示用户消息可能被篡改，建议通过其他渠道核实。

总结与方案选择

对于任何严肃的 Web IM 应用，请务必选择方案三。它虽然实现复杂，但能同时满足安全性、性能和用户体验的要求。