Web IM 聊天信息加密的三种实现方案对比与实战

Web IM 聊天信息加密的三种实现方案对比与实战

即时通讯（IM）中的隐私保护至关重要。传统的 HTTPS 只能保证传输安全，无法防止服务器端的数据泄露。端到端加密（E2EE）确保消息在发送方客户端加密，直到接收方客户端才解密，中间过程对服务器不可见。

核心密码学概念速览

在深入代码之前，先理清几个关键概念，这决定了我们后续的技术选型：

1. 对称加密 (Symmetric Encryption)：如 AES。速度快，适合大量数据，但密钥分发是难题。
2. 非对称加密 (Asymmetric Encryption)：如 RSA、ECC。公钥加密私钥解密，解决了密钥分发问题，但速度慢。
3. 混合加密系统：结合两者优点。用非对称加密交换会话密钥，再用对称加密传输消息。这是 TLS 和现代 E2EE 的标准做法。
4. 数字签名：用于验证身份和完整性，防止篡改和抵赖。
5. 前向保密 (Forward Secrecy)：即使长期私钥泄露，过去的通信记录依然安全。生产环境必备。

前端开发中，node-forge 功能全面且兼容性好；后端 Java 标准库 javax.crypto 足够强大。下面我们通过三个递进的方案来实战落地。

方案一：静态非对称加密（基础版）

这个方案最直观，每个用户拥有一对固定的长期密钥。发送者直接用接收者的公钥加密每一条消息。

流程简述

1. 注册时生成 RSA 密钥对，私钥存本地，公钥传服务器。
2. A 发消息给 B，A 获取 B 的公钥并加密消息。
3. 服务器转发密文，B 用私钥解密。

前端 Vue 实现要点

安装依赖后，我们需要一个工具类来处理加解密。注意这里使用了 OAEP 填充，比 PKCS#1 v1.5 更安全。

// utils/crypto.js
import forge from 'node-forge';

export function generateRSAKeyPair() {
  return new Promise((resolve, reject) => {
    forge.pki.rsa.generateKeyPair({ bits: 2048, workers: 2 }, (err, keypair) => {
      if (err) { reject(err); return; }
      const publicKey = forge.pki.publicKeyToPem(keypair.publicKey);
      const privateKey = forge.pki.privateKeyToPem(keypair.privateKey);
      resolve({ publicKey, privateKey });
    });
  });
}

export function encryptMessageWithPublicKey(publicKeyPem, message) {
  try {
    const publicKey = forge.pki.publicKeyFromPem(publicKeyPem);
    const encodedMessage = forge.util.encodeUtf8(message);
    // 使用 OAEP 填充进行加密，SHA-256 作为摘要算法
    const encrypted = publicKey.encrypt(encodedMessage, 'RSA-OAEP', {
      md: forge.md.sha256.create(),
    });
    return forge.util.encode64(encrypted);
  } catch (error) {
    console.error('加密失败:', error);
    throw new Error('消息加密失败');
  }
}

export function decryptMessageWithPrivateKey(privateKeyPem, encryptedMessageBase64) {
  try {
    const privateKey = forge.pki.privateKeyFromPem(privateKeyPem);
    const encryptedData = forge.util.decode64(encryptedMessageBase64);
    const decrypted = privateKey.decrypt(encryptedData, 'RSA-OAEP', {
      md: forge.md.sha256.create(),
    });
    return forge.util.decodeUtf8(decrypted);
  } catch (error) {
    console.error('解密失败:', error);
    throw new Error('消息解密失败，可能是密钥不匹配或消息已损坏');
  }
}

在组件中使用这个工具类时，要注意性能问题。RSA 加密非常消耗 CPU，频繁发送消息会导致界面卡顿。

后端 Java 实现要点

后端角色较轻，主要负责存储公钥和转发消息。Spring Boot 配合 WebSocket 即可。

// ChatController.java
@RestController
@RequestMapping("/api/chat")
public class ChatController {
    @Autowired private UserRepository userRepository;
    @Autowired private SimpMessagingTemplate messagingTemplate;

    // 获取指定用户的公钥
    @GetMapping("/user/{userId}/public-key")
    public ResponseEntity<?> getUserPublicKey(@PathVariable Long userId) {
        User user = userRepository.findById(userId).orElseThrow(() -> new ResourceNotFoundException("User not found"));
        if (user.getRsaPublicKey() == null) {
            return ResponseEntity.badRequest().body("User does not have a public key");
        }
        return ResponseEntity.ok().body(Collections.singletonMap("publicKey", user.getRsaPublicKey()));
    }

    // 接收并转发加密消息
    @PostMapping("/message")
    public ResponseEntity<Void> sendEncryptedMessage(@RequestBody EncryptedMessageRequest request) {
        // 1. 验证发送者身份
        // 2. 将消息保存到数据库（存密文）
        // 3. 通过 WebSocket 实时转发给接收者
        String destination = "/queue/messages";
        MessageDeliveryDto deliveryDto = new MessageDeliveryDto();
        // ... 填充字段 ...
        messagingTemplate.convertAndSendToUser(request.getReceiverId().toString(), destination, deliveryDto);
        return ResponseEntity.ok().build();
    }
}

方案一优缺点总结

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

方案二：非对称加密 + 数字签名（增强版）

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

核心逻辑

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

前端增强实现

需要在工具类中增加签名和验签函数。

// utils/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) {
    console.error('签名失败:', 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) {
    console.error('验证签名失败:', error);
    return false;
  }
}

方案二优缺点总结

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

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

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

为什么选它？

• 高性能：消息通信使用高效的对称加密（AES）。
• 前向保密：会话密钥是临时的，定期更换。即使长期私钥泄露，过去通信依然安全。
• 安全性：结合了非对称加密的安全密钥分发和对称加密的效率。

前端 Vue 实现（重大修改）

我们需要一个会话密钥管理机制，通常放在 Vuex Store 中。

// store/modules/chatSession.js
const state = {
  sessionKeys: {}, // { [targetUserId]: { key: '...', iv: '...' } }
};

const mutations = {
  SET_SESSION_KEY(state, { userId, keyData }) {
    state.sessionKeys[userId] = { ...keyData, timestamp: Date.now() };
  },
  CLEAR_ALL_SESSIONS(state) {
    state.sessionKeys = {};
  },
};

const actions = {
  async establishSession({ commit, rootState }, targetUserId) {
    try {
      // 1. 生成对称密钥
      const symmetricKey = generateSymmetricKey();
      // 2. 获取目标用户的公钥
      const publicKeyResponse = await apiGetUserPublicKey(targetUserId);
      const receiverPublicKey = publicKeyResponse.data.publicKey;
      // 3. 用对方的公钥加密我们的对称密钥（创建信封）
      const encryptedEnvelope = encryptSymmetricKeyWithPublicKey(receiverPublicKey, symmetricKey);
      // 4. 发送密钥交换消息
      await apiSendKeyExchange({ receiverId: targetUserId, encryptedEnvelope });
      // 5. 将会话密钥保存在本地 Store 中
      commit('SET_SESSION_KEY', { userId: targetUserId, keyData: symmetricKey });
      return symmetricKey;
    } catch (error) {
      console.error('建立会话失败:', error);
      throw new Error('无法建立安全会话');
    }
  },
};

在发送消息时，不再直接调用 RSA 加密，而是先获取会话密钥，再用 AES 加密。

// components/Chat.vue - sendMessage 方法
async sendMessage() {
  if (!this.newMessage.trim()) return;
  try {
    // 1. 获取或创建与目标用户的会话密钥
    const sessionKeyData = await this.$store.dispatch('chatSession/getOrCreateSessionKey', this.targetUser.id);
    // 2. 使用对称密钥加密消息 (非常快)
    const encryptedContent = encryptWithSymmetricKey(
      sessionKeyData.key,
      sessionKeyData.iv,
      this.newMessage.trim()
    );
    // 3. 发送消息
    const messagePayload = {
      receiverId: this.targetUser.id,
      content: encryptedContent,
      isSymmetric: true,
      timestamp: new Date().toISOString(),
    };
    this.websocket.send(JSON.stringify(messagePayload));
    // 4. 乐观更新 UI
    this.messages.push({ id: Date.now(), sender: this.currentUser.id, decryptedContent: this.newMessage.trim() });
    this.newMessage = '';
  } catch (error) {
    console.error('发送消息失败:', error);
  }
}

高级特性：双工密钥协商与 Perfect Forward Secrecy

更安全的做法是使用 ECDH（椭圆曲线 Diffie-Hellman）协议。双方各自生成临时密钥对，交换公钥后计算共享密钥。这样每次会话的密钥都是独立的，彻底实现了完全的前向保密。

// 概念性代码，使用 libsodium.js
import sodium from 'libsodium-wrappers';
await sodium.ready;
let keyPairA = sodium.crypto_kx_keypair();
let keyPairB = sodium.crypto_kx_keypair();
// A 计算共享密钥
let sharedKeyA = sodium.crypto_kx_client_session_keys(keyPairA.publicKey, keyPairA.privateKey, keyPairB.publicKey);
// B 计算共享密钥
let sharedKeyB = sodium.crypto_kx_server_session_keys(keyPairB.publicKey, keyPairB.privateKey, keyPairA.publicKey);
// sharedKeyA.rx === sharedKeyB.tx

方案三优缺点总结

• 优点：高性能、前向保密、高安全性。
• 缺点：实现复杂度最高，需要管理会话状态和密钥生命周期。
• 结论：唯一推荐用于生产环境的方案。

部署与安全最佳实践

1. 密钥安全存储

• 长期私钥：不要明文存储在 localStorage 中，容易被 XSS 攻击窃取。建议使用用户密码派生出的密钥对私钥进行二次加密后再存储。
• 会话密钥：可以存在 Vuex 内存中，刷新即丢失（增强前向保密）。如需持久化，加密后存入 IndexedDB。

2. 传输安全

• 必须使用 HTTPS 和 WSS 协议，防止中间人攻击。

3. 后端安全

• 所有 API 调用需严格身份验证（JWT）。
• 实施速率限制，防止滥用。

总结

特性	方案一：静态非对称	方案二：静态 + 签名	方案三：混合加密
安全性	低	中	高
性能	极差	非常差	优秀
前向保密	无	无	有
推荐场景	学习原型	低频验证	生产环境

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