應項目安全需求，現有工程中使用到的配置文件需要加密保護，提升產品安全性。
設計調研
考慮到是本地加密，先在現有工程中梳理一趟已有的加密方式，除去網絡模塊的非對稱加密方式之外，其他涉及到關鍵敏感信息都采用了對稱加密。在工程中有多種實現，大致總結如下：
- 在已有的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加密解密 和 海奼網 進行驗證。