1. 项目概述：当加密技术穿上“隐身衣”

最近在捣鼓鸿蒙应用开发，我琢磨着做点不一样的东西。传统的加密App，比如你给文件加密，输出来的要么是一串乱码，要么是Base64编码，明眼人一看就知道“这玩意儿被加密了”。这就像在保险箱上贴了个“内有黄金”的标签，虽然打不开，但招贼。于是我就想，能不能让加密后的结果，看起来就像一段普普通通、甚至文从字顺的中文段落？比如，你加密了一段机密信息，输出的密文是“今日天气晴好，宜出行访友，记得带伞以防万一。”这种看起来毫无破绽的日常句子。

这个想法催生了我的这个小项目：一个运行在HarmonyOS上的加密App，核心是 AES-GCM 现代加密算法与 字谱替换 技术的结合。AES-GCM负责提供坚不可摧的机密性和完整性校验，确保内容绝对安全；而字谱替换则像一位顶级的“伪装大师”，将加密后的二进制密文，“翻译”成一段符合语法、语义通顺的中文。这样一来，加密信息就能大隐隐于市，混迹于日常聊天、笔记甚至公开文档中，极大地提升了隐蔽性。

这个项目适合对鸿蒙应用开发、现代密码学应用，或者对信息隐蔽技术感兴趣的朋友。它不只是一个简单的加密工具实现，更涉及了跨领域的思路融合：如何在保证最高等级安全性的前提下，优雅地解决密文的“形态”问题。下面，我就来详细拆解整个实现思路、关键细节以及我踩过的那些坑。

2. 核心架构与方案选型

要实现“密文像正常中文”这个目标，整个系统需要分为前后两个核心阶段，并且对每个阶段的技术选型都有严苛的要求。

2.1 第一阶段：坚不可摧的加密内核——为何选择 AES-GCM

加密是安全的基石，这里绝对不能妥协。我放弃了古老的ECB、CBC模式，甚至没有考虑单纯的AES-CTR，而是直接选用了 AES-GCM 。

为什么是AES-GCM？ 这得从它的三大特性说起：

1. 认证加密 ：这是GCM模式的核心。它不仅在加密时生成密文，还会同时生成一个“消息认证码”。在解密时，会先验证这个认证码。任何对密文的篡改（哪怕只是一个比特），都会导致验证失败，解密过程直接中止。这就像给你的加密文件加上了一个一次性封条，一旦被撕开或调换，立刻就能发现。对于需要确保信息完整性和真实性的场景，这是必选项。
2. 并行计算与高性能 ：GCM模式在设计上支持并行化处理，在现代CPU上运行效率非常高。对于移动设备而言，能在保障安全的同时减少性能损耗和电量消耗，用户体验更好。
3. 无需填充 ：GCM属于流密码模式，它通过生成密钥流与明文进行异或来加密，因此明文长度就是密文长度，没有填充带来的额外数据膨胀问题。这为后续的“字谱替换”阶段提供了便利，因为我们需要处理的是固定长度的二进制数据。

在鸿蒙平台上，我们可以通过 @ohos.security.cryptoFramework 这个系统API来调用AES-GCM。它封装了底层的安全硬件（如TEE）或软件实现，我们无需自己实现复杂的算法，只需关注正确的使用方式。

2.2 第二阶段：以假乱真的形态伪装——字谱替换的精髓

AES-GCM输出的是二进制数据（通常我们会用十六进制或Base64表示）。如何将它变成中文？这就是“字谱替换”大显身手的地方。

核心思路 ：建立一个庞大的、双向可查的映射表。这个表的一边是“字谱单元”（可以是一个汉字，也可以是一个常见词组），另一边是固定长度的二进制数据块（例如2个字节，即0-65535的范围）。

运作流程 ：

1. 编码（加密后） ：将AES-GCM产生的二进制密文，按固定长度（比如2字节）进行切分。每一个2字节的数据块（值范围0-65535），都在映射表中查找对应的一个“字谱单元”。将这些字谱单元按顺序拼接，就形成了一段中文文本。
2. 解码（解密前） ：将收到的一段中文文本，按字或词进行分割，然后在映射表中反向查找每个“字谱单元”对应的二进制数据块，拼接还原出原始的二进制密文，再交给AES-GCM解密。

关键在于映射表的构建 ，这直接决定了伪装效果的好坏：

• 词库质量 ：不能随便找一本字典。我们需要的是高频、常用、组合起来能形成自然语句的汉字和词语。例如，“的”、“了”、“在”、“今天”、“天气”、“我们”等。可以从现代汉语语料库中提取词频最高的前几万个单元。
• 语义连贯性 ：单纯的随机映射，出来的句子可能是“苹果吃饭蓝色跑步”，这显然不正常。因此，在构建映射表时，需要引入简单的语言模型或规则，确保相邻的“字谱单元”在词性和语义上有一定的搭配可能性，从而生成“看似合理”的句子。这部分是项目中最具挑战性和创意性的环节。
• 映射表的安全 ：这个映射表本身就是密钥的一部分！如果攻击者拿到了你的映射表，他就能轻易地将任何一段伪装中文还原成二进制密文进行破解。因此，映射表必须作为核心机密，与AES的密钥分开保存，最好能由用户自定义或通过密钥派生算法动态生成。

3. 鸿蒙端核心实现细节

理论清晰后，我们来看在HarmonyOS应用中如何具体实现。这里会涉及ArkTS/JS的代码片段，并解释关键参数的选择。

3.1 AES-GCM 加密/解密模块实现

首先，我们需要在鸿蒙应用的 entry/src/main/resources/base/profile/ 下的 module.json5 文件中声明加密能力。

{
  "module": {
    // ... 其他配置
    "requestPermissions": [
      {
        "name": "ohos.permission.USE_CRYPTOGRAPHY" // 请求加解密权限
      }
    ]
  }
}

接下来是核心的加密函数。这里我选择 AES-256-GCM ，密钥长度256位，安全性足够高。初始化向量（IV）必须是随机且唯一的，每次加密都应不同，这里使用12字节（96位），这是GCM模式的推荐长度。

import cryptoFramework from '@ohos.security.cryptoFramework';
import util from '@ohos.util';

async function aesGcmEncrypt(plainText: string, key: Uint8Array): Promise<{cipherData: Uint8Array, iv: Uint8Array, authTag: Uint8Array}> {
  // 1. 创建对称密钥生成器，指定AES256
  let symKeyGenerator = cryptoFramework.createSymKeyGenerator('AES256');
  let symKey = await symKeyGenerator.convertKey({ data: key });

  // 2. 创建加密器，指定GCM模式及PKCS7填充（虽然GCM无需填充，但API可能需要）
  let cipher = cryptoFramework.createCipher('AES256|GCM|PKCS7');

  // 3. 生成随机IV (12字节)
  let iv = new Uint8Array(12);
  for (let i = 0; i < iv.length; i++) {
    iv[i] = Math.floor(Math.random() * 256);
  }
  let ivParam = cryptoFramework.createIvParamsSpec(iv);

  // 4. 设置GCM模式额外参数：IV和认证数据长度（这里设为128位）
  let gcmParams = cryptoFramework.createGcmParamsSpec(iv, null, 16); // 16字节 = 128位认证标签
  await cipher.init(cryptoFramework.CryptoMode.ENCRYPT_MODE, symKey, gcmParams);

  // 5. 执行加密
  let inputData: cryptoFramework.DataBlob = { data: stringToUint8Array(plainText) };
  let encryptData = await cipher.doFinal(inputData);

  // 6. 获取认证标签（Auth Tag）
  // 注意：鸿蒙cryptoFramework的GCM模式，doFinal结果可能已经包含了密文和认证标签，需要根据API文档拆分。
  // 这里假设encryptData.data包含密文，我们需要通过cipher.getCipherSpec().getAuthTag()获取标签（如果API支持）。
  // 以下为示意逻辑，实际需查阅最新API。
  let authTag: Uint8Array;
  // ... 根据实际API获取authTag ...

  return {
    cipherData: new Uint8Array(encryptData.data.buffer),
    iv: iv,
    authTag: authTag
  };
}

// 辅助函数：字符串转Uint8Array
function stringToUint8Array(str: string): Uint8Array {
  let encoder = new util.TextEncoder();
  return encoder.encodeInto(str);
}

关键点解析 ：

1. IV的随机性与唯一性 ：每次加密都必须使用新的随机IV，绝对不能复用。复用IV在GCM模式下会导致灾难性的安全漏洞。
2. 认证标签长度 ：这里设置为16字节（128位）。更长的标签（如15或16字节）提供更高的安全性，但也会增加密文长度。128位对于绝大多数应用已足够。
3. API适配 ：鸿蒙的 cryptoFramework API仍在演进中，对于GCM模式认证标签的获取方式，务必查阅对应版本的最新开发文档。可能需要通过 getCipherSpec() 等方法获取。

解密函数是加密的逆过程，需要提供密文、IV、认证标签和密钥。解密时会自动验证认证标签，失败则抛出异常。

3.2 字谱替换引擎的设计

这是项目的“灵魂”。我们首先需要构建那个庞大的映射表。在实际项目中，这个表可能是一个预制的、序列化的二进制文件或JSON文件，在应用初始化时加载到内存中。

简化版映射表示例（JSON格式） ：

{
  "0": "今天",
  "1": "天气",
  "2": "很好",
  "3": "我",
  "4": "们",
  "5": "去",
  "6": "公园",
  "7": "玩",
  // ... 一直到 65535
}

但这样映射出来的句子质量很差。更高级的做法是使用 双字词 或 三字词 作为基本单元，并建立基于统计的转移概率，让生成的句子更自然。

编码过程（二进制 -> 中文） ：

// 假设 cipherData 是 AES-GCM 加密后的二进制数据 (Uint8Array)
// 假设 mappingTable 是一个 Map<number, string>， key是0-65535的值，value是中文词
function encodeToChinese(cipherData: Uint8Array, mappingTable: Map<number, string>): string {
  let result = '';
  // 将Uint8Array转换为16位视图，每2个字节作为一个编码单元
  let dataView = new DataView(cipherData.buffer);
  for (let i = 0; i < cipherData.length; i += 2) {
    let codeUnit: number;
    if (i + 1 < cipherData.length) {
      codeUnit = dataView.getUint16(i, false); // false 表示大端序，可根据需要调整
    } else {
      // 处理最后一个字节（奇数长度情况），可以填充或特殊处理
      codeUnit = dataView.getUint8(i) << 8; // 左移8位，低字节补0
    }
    // 查找映射表，如果找不到则使用一个默认词（如“的”）
    let word = mappingTable.get(codeUnit) || '的';
    result += word;
  }
  return result;
}

解码过程（中文 -> 二进制） ： 这比编码更复杂，因为中文文本没有显式的分词。我们需要一个 最大正向匹配算法 ，在映射表的词库中查找最长的匹配词。

function decodeFromChinese(chineseText: string, reverseMappingTable: Map<string, number>): Uint8Array {
  let binaryChunks: number[] = [];
  let i = 0;
  const textLen = chineseText.length;

  while (i < textLen) {
    let matched = false;
    // 从最大可能长度（比如4个字符）开始尝试匹配
    for (let len = Math.min(4, textLen - i); len > 0; len--) {
      let segment = chineseText.substr(i, len);
      if (reverseMappingTable.has(segment)) {
        binaryChunks.push(reverseMappingTable.get(segment)!);
        i += len;
        matched = true;
        break;
      }
    }
    if (!matched) {
      // 遇到无法识别的字符，可能是干扰信息或错误，这里选择跳过并记录错误
      console.error(`无法解码字符: ${chineseText[i]}`);
      i++; // 跳过这个字符
    }
  }

  // 将16位数值数组转换回Uint8Array
  let buffer = new ArrayBuffer(binaryChunks.length * 2);
  let dataView = new DataView(buffer);
  for (let j = 0; j < binaryChunks.length; j++) {
    dataView.setUint16(j * 2, binaryChunks[j], false);
  }
  return new Uint8Array(buffer);
}

实操心得与避坑指南 ：

1. 映射表加载性能 ：如果映射表很大（几万条），直接解析JSON会慢且耗内存。可以考虑预编译成二进制格式，或使用鸿蒙的轻量级KV存储进行分块加载。
2. 分词歧义 ：“今天天气很好”可以被切分为“今天/天气/很好”，也可能被错误切分为“今/天天/气很/好”。一个健壮的系统需要处理这种歧义。除了最大匹配，还可以结合词频统计，或者要求生成的密文文本中包含不参与解码的“分隔符”或采用定长编码（每个词固定字数），但这会降低自然度。
3. 容错性 ：伪装文本在传输中可能被修改、插入空格或标点。解码算法需要有一定的容错能力，比如忽略空格和常见标点，或者使用纠错码。

4. 完整工作流程与用户体验设计

一个完整的加密操作，用户感知到的流程应该是极其简单的，但背后经历了复杂的转换。

4.1 加密流程

1. 用户输入 ：用户在App界面输入明文（如“明天下午三点老地方见”），并输入一个强密码。
2. 密钥派生 ：使用PBKDF2等算法，将用户密码和随机盐值转换成AES-256所需的密钥。盐值需要保存。
3. AES-GCM加密 ：使用派生的密钥，对明文进行加密，得到二进制密文、IV和认证标签。
4. 二进制到整数序列转换 ：将二进制密文按2字节分组，转换成一系列0-65535的整数。
5. 字谱替换 ：根据映射表，将每个整数替换成对应的中文词，并拼接成段落。为了更自然，可以在段落前后加上一些通用的、与上下文无关的“上下文包装句”，如“随笔记录：”和“——完”。
6. 输出 ：最终呈现给用户的，是一段如“随笔记录：午后阳光透过窗棂，洒在慵懒的茶杯边缘，猫咪蜷缩在沙发一角，做着它的春秋大梦。——完”这样的文本。用户可以将其复制到任何地方。

4.2 解密流程

1. 用户输入 ：用户粘贴回那段“正常”的中文文本。
2. 文本预处理 ：去除“上下文包装句”等已知的非密文部分。
3. 中文到整数序列转换 ：使用最大匹配算法和反向映射表，将中文文本解码成整数序列。
4. 整数序列到二进制 ：将整数序列转换回二进制数据（即AES-GCM的密文）。
5. AES-GCM解密 ：使用用户输入的密码（派生密钥）、保存的盐值和IV，对二进制数据进行解密和认证标签验证。如果验证通过，则显示原始明文；否则提示“信息已被篡改或密码错误”。

界面设计要点 ：

• 结果展示区 ：加密后的中文文本应在一个可轻松复制的 TextArea 中显示，并配有“一键复制”按钮。
• 历史记录 ：使用鸿蒙的 RDB 或 Preferences 数据库，安全地存储每次加密操作的元数据（如盐值、IV的索引或加密时间），但绝不能存储密钥或映射表。
• 密码管理 ：强烈建议引导用户使用密码管理器生成和保存强密码，App本身不提供密码找回功能，这是现代安全应用的基本原则。

5. 安全增强、问题排查与进阶思考

实现基本功能只是第一步，要让这个App真正可靠，还需要考虑更多。

5.1 安全性增强措施

1. 密钥管理 ：用户密码不能直接用作AES密钥。必须使用 PBKDF2 或 Scrypt 这类密钥派生函数，加入随机盐值和足够高的迭代次数（如10万次），以抵御暴力破解。
2. 映射表动态化 ：将映射表与用户主密钥进行关联派生。例如，使用HKDF从主密钥派生出另一个密钥，用于加密一个标准的映射表种子，从而生成用户独有的映射表。这样即使标准映射表泄露，没有用户密钥也无法使用。
3. 抗分析 ：生成的伪装文本，其词频分布应尽可能接近真实自然语言。可以引入简单的n-gram语言模型进行优化，避免出现“的的的”这类不自然重复。
4. 完整性延伸 ：AES-GCM保证了密文完整性，但伪装后的中文文本在传输中可能被增删修改。可以在字谱替换阶段，在二进制数据末尾附加一个CRC32或HMAC校验码（同样编码为中文词），在解码后先进行校验，提前发现传输错误。

5.2 常见问题与调试技巧

• 问题 ：解密时总是失败，提示认证失败。

• 排查 ：这是最常见的问题。请按顺序检查：1) 用于解密的密码是否与加密时完全一致（包括大小写和空格）？2) 解密时使用的IV是否与加密时生成的IV完全一致？3) 用于解密的认证标签是否正确？4) 密文（二进制数据）在编码/解码过程中是否发生了任何改变？ 调试时，可以将IV、认证标签和加密后的二进制数据（Hex格式）打印出来，对比加密和解密两端是否完全相同。

• 问题 ：生成的中文文本非常生硬，不像人话。

• 排查 ：检查你的映射表。是否只使用了单字？尝试引入更多的高频双字词、三字词和短句。可以尝试用马尔可夫链模型来生成更连贯的文本，但这会显著增加复杂度。

• 问题 ：App在解码长文本时非常慢。

• 排查 ：最大匹配算法的复杂度是O(n^2)。对于长文本，性能可能成为瓶颈。可以考虑：1) 将反向映射表的数据结构从 Map 换成 Trie （前缀树），这是解决字符串前缀匹配问题的标准高效数据结构。2) 对生成的伪装文本长度设一个合理上限。

• 问题 ：鸿蒙API cryptoFramework.createCipher(‘AES256|GCM|PKCS7’) 报错或不支持。

• 排查 ：首先确认你的HarmonyOS SDK版本。查阅官方文档，确认 GCM 模式是否完全支持。有时可能需要使用 NONE 作为填充模式，或者API名称有细微差别。社区论坛和官方示例代码是最好的参考资料。

5.3 进阶可能性

这个项目的思路可以进一步扩展：

• 多语言支持 ：字谱替换不限于中文，可以适配英文、日文等任何语言，生成看似正常的英文段落或推特推文。
• 富媒体伪装 ：将密文编码后，藏入图片的LSB（最低有效位）或音频文件的特定频段，再结合Steganography（隐写术）技术，实现更深层的隐藏。
• 上下文感知生成 ：结合大语言模型（LLM）的API，让生成的伪装文本不仅语法正确，还能围绕一个给定的主题展开，使其在特定语境下天衣无缝。当然，这需要处理网络请求和API成本。

做这个项目的过程中，我最大的体会是，安全是一个系统工程。AES-GCM提供了数学上坚固的堡垒，而字谱替换则赋予了它一层巧妙的迷彩。两者结合，才能应对更复杂的现实场景。在鸿蒙这样的新兴生态中实践这些想法，既能深入理解系统安全API的用法，也能探索人机交互与安全性的有趣结合点。最后，记住安全的第一原则：永远不要自己发明加密算法，使用经过时间检验的、标准的、被广泛审计的库，并把它们用对地方。