加密配置文件总结

应项目安全需求，现有工程中使用到的配置文件须要加密保护，提高产品安全性。

设计调研

考虑到是本地加密，先在现有工程中梳理一趟已有的加密方式，除去网络模块的非对称加密方式以外，其余涉及到关键敏感信息都采用了对称加密。在工程中有多种实现，大体总结以下：

• 在已有的AES-ECB加密模块的基础上，增长输出hex编码的加密类。
• 异或加解密类，使用随机生成的字符进行自定义的异或加密处理
• 在Windows内置的加密套件基础上封装的加密类
• Rijndael加密组件，该组件提供的接口支持ECB、CBC和CFB三种AES加密方式，提供的接口较完善。

本地配置文件的编码方式有txt、xml和json三种格式，使用tinyxml来解析xml，使用jsoncpp来解析json格式，文本格式直接读取。
在最处的设计中，尝试把加解密的功能做为基类，各个具体解析类做为派生类，类图以下：

在进行基础功能的开发和测试时，发现加解密功能和具体的解析功能是正交独立的，他们之间没有父子关系，而应该是组合的关系。考虑到现有程序中已有的基于tinyxml更高一层级的封装 XML 读写类，为了复用已有代码，在 读取加密xml 的类中，应该组合 已有的XML读写类。

加解密功能由内部加密组件成员实现，读写功能转发给已有的 CXMLFile来实现。

实现过程

肯定待加密文件列表

通常来讲，服务器链接信息、本地功能配置信息、版本信息等文件须要加密保存。对于用户可以设置并生成的文件，在设置时，再调用加密方法进行加密保存，而已有的设置文件无需加密保存，由于它已是密文的。

肯定影响范围

有些特定的配置文件是须要按期从服务器更新的，也有些须要在升级时被覆盖升级。所以，对于加密文件，在服务端下发时，也要采用同客户端一样的加密策略，保证客户端可以正确解析加密文件。

若是待加密文件有被其余组件读取的场景，则在加密后要通知相关组件负责人采用加解密的方式来读取待加密文件。

开发建议

在选择密钥和初始化向量时，虽然说能够随便输入，经本人自测，发如今一些 在线AES加密解密
网站上，初始化向量设置中含有 % 和 & 两种字符时，得不到正确的结果，提示 偏移量最少：16字节长度,而在海姹网网页上，不会有这样的问题。猜想多是在处理IV输入时，对特殊字符考虑不完善致使的结果。为了便于自测和测试人员回归验证，建议初始化向量中不要包含 % 和 & 两种字符。

因为AES加密输出的字符可能存在数字0的状况，为了便于后续的字符串操做，建议对输出进行base64加密，在解密时，先进行base64解密，再进行aes解密，最后对输出填充的内容进行去除，获得原始明文。

测试建议

考虑到开发自测和后续测试人员的测试便利性，开发人员要提供与客户端同样的加解密文件测试工具，可以解析密文，也可以验证加密算法的正确性。说到验证加密算法的正确性，最简单的就是同网上的在线AES加密网页进行对比，这里总结下本身遇到的一些坑。

在线AES加解密网址：

1. 在线AES加密解密
2. aes加密
3. 海姹网
4. Json在线
5. 脚本之家在线工具
6. AES在线工具

以上序号为一、二、3的网站，对AES加密有较完善的参数输入，4，5,6网站加密功能简单，体验很差。在网站一、二、3中，对于一样输入的加密参数，1和3网站输出同样，网站2输出的不同。通过本身测试，本身程序中输出的结果同一、3网站一致，所以，能够判断网站2内部计算是有问题的，不建议使用。建议使用 在线AES加密解密 和 海姹网 进行验证。