加密解密--换行符作祟

     最近在对于某一个（省略）功能进行联调功能：

大致需求：消息以JSON格式显示--JSON分为消息头（header），消息体（body)，消息签名(mac)--通过AES对body内部值进行加密，通过MD5对header+body信息进行加密成mac值；

其实思路真的很简单，但是在测试上真的是测试的不少的天数，原因何在呢？

测试缓慢的原因：

• 1、对于需求细节还欠缺了解-->到底对谁加密？加密前后关系，先对body加密，还是先加密成mac？……
• 2、对于细节研究不专心-->最后的一根稻草被加密过程中的换行符所压倒；

     本篇主要还是对于加密过程中的过程进行分析：

     在测试的过程中，愈来愈发现自己的赋值已经没有了问题，但是为何加密之后，传回来的响应报文却总是"报文错误（mac解析错粗），到底是哪里出现了问题？

• 分析一：通过AESTools1.jar工具进行测试，对比自己的代码以及其工具生成是否保持一致；
• 分析二：仔细查询结果，从发送报文加密前后进行分析；

     首先对于分析一而言：当拿到这个jar的时候，你是否能够快速的响应？到底该如何使用？在这里有两种思考：思考一，我不想进行返回值对比，只想使用其中的某个类，比如：AesEncrypt加密解密类，我该如何处理？首先使用解压工具对其进行解压操作；

     但是其类型并非是.java类型，我们可以采用反编译工具比如：JD-GUI 来进行反编译操作。最后可以很方便的看到自己想要的代码类，我们直接选择我们想要的即可。

     除了使用其jar包中的代码为我所用，我们可以直接使用这个工具对其结果进行分析对比操作。

     通过dos窗口，执行操作：java -jar jar包路径

     分析二：对于分析一而言，自己并没有找到什么问题，一切都很顺利，那么到底是哪里的问题？自己对比body,mac加密前后以及自己最后的请求报文自己发现了问题：

     红色标记部分body加密信息为何不一致？自己分析就会发现居然在自己的眼皮之下多了"换行符"!!自己对于body是通过AES加密的，在调试的过程中，其实很容易发现：

     Base64加密到了一定长度会自动换行，就如上图所示，所以必须得想办法去掉换行符。如上图所示直接加密之后对其进行操作可以，同样也可以在其根源Base64加密方法上进行replaceAll操作，这样避免本模块大量的加密过程多次换行操作。

 

本篇主要还是讲述了两点：

• 点一：反编译软件的使用；
• 点二：加密过程中换行符的使用；

行是知之始，知是行之成。——陶行知