加密配置文件总结
应项目安全需求，现有工程中使用到的配置文件需要加密保护，提升产品安全性。
设计调研
考虑到是本地加密，先在现有工程中梳理一趟已有的加密方式，除去网络模块的非对称加密方式之外，其他涉及到关键敏感信息都采用了对称加密。在工程中有多种实现，大致总结如下：
- 在已有的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、2、3的网站，对AES加密有较完善的参数输入，4，5,6网站加密功能简单，体验不好。在网站1、2、3中，对于同样输入的加密参数，1和3网站输出一样，网站2输出的不一样。经过自己测试，自己程序中输出的结果同1、3网站一致，因此，可以判断网站2内部计算是有问题的，不建议使用。建议使用 在线AES加密解密 和 海姹网 进行验证。
