# 如何解决AES加解密报错问题

#### 问题现象

加解密常用于数据存储或传输场景，在使用对称密钥加解密算法AES进行数据加解密操作时产生错误，常见执行加解密时抛出错误码17630001、密钥转换失败、执行加解密时闪退等现象。

#### 背景知识

*   对称密钥算法：加密和解密使用相同的密钥，常见算法为AES、DES、SM4等，要求通信双方必须在传输数据前安全地分享密钥。
*   AES：AES为分组加密算法，分组长度为128位。在实际应用中，最后一组明文可能不足128位（16字节），此时可以通过不同的填充模式进行数据填充。

#### 问题定位

针对AES加解密错误问题定位可结合问题现象和DEBUG调试开展。

*   加解密闪退问题：dofinal方法是加解密操作关键节点，执行加解密操作时通过DEBUG单步调试观察是否为此处导致应用闪退。
*   17630001等报错问题：此类问题原因通常是由于API入参使用错误、加密和解密方法入参不一致、明文长度与算法不匹配、数据格式与算法不匹配等问题造成，因此可按照以下步骤进行排查：
    1.  将明文数据转换为Uint8Array格式，检查长度是否为128的整数倍。
    2.  检查入参是否格式正确，例如AES|CFB|NoPadding是否输入为AES/CFB/NoPadding。
    3.  检查算法入参是否与密钥长度匹配，例如AES128对应的密钥长度也需要为128bit。
    4.  检查明文或密文转换编码格式方法是否正确，入参为Uint8Array格式，实际应用中需要将Base64等数据编码格式转换，检查转码方法是否正确。
    5.  检查加密参数与解密参数是否一致，包含加密算法密钥长度、填充模式、密钥、CBC模式对应的解密参数IvParamsSpec等。

#### 分析结论

*   加解密执行dofinal方法时出现闪退通常是因为Cipher实例的init方法为异步函数，还未完成初始化时程序已经执行加解密dofinal操作导致发生闪退。
*   17630001等报错问题：
    1.  采用ECB、CBC加密模式，明文长度不是128位整数倍，必须使用填充方法补足，不可选择NoPadding。
    2.  入参格式未与API入参要求保持一致，传入错误格式。
    3.  所采用的密钥为其他平台已有密钥，为满足算法要求对密钥长度做截取或补位操作，但在ArkTS侧未做同样处理，导致密钥长度与算法要求不一致。
    4.  明文或密钥数据做转码时操作错误，如将16进制字符串采用Base64的转码方式处理。
    5.  加密方法的入参未与解密方法入参保持一致，如AES采用CBC模式下加密与解密方法的入参IvParamsSpec各自生成一份。

#### 修改建议

*   加解密方法同时提供异步方法和同步方法，在使用异步方法时可通过await方式保障Cipher实例先初始化再加解密，可参考使用AES对称密钥（CBC模式）加解密(ArkTS)示例。
*   加解密操作仅用于ArkTS侧时可结合以上示例正确选择算法入参和调用方式，若涉及与服务端等交互，可参考服务端加密的密文填充方式、数据编码格式等进行调整，保障加密模式与服务端一致。

#### 总结

加解密操作通常涉及跨服务端与其他客户端平台的互通操作，AES算法作为常用的对称密钥加解密算法，需要在使用过程中保障加密方法与解密方法的入参一致，包含密钥、数据填充模式等。