写在前
对工作中遇到的加密算法算法进行总结和思考，分析不同加密算法优缺点和对应解决问题场景，思考进一步可改进点。
场景1、加密算法在链接防止抓取中应用
客户端和服务器端对(appverision+url+盐+offset)使用加密规则进行加密，对传输数据进行签名，则进行正常业务处理，否则直接拒绝请求。为了加密算法的隐私性，仅对小部分开发者可见，客户端和服务器过滤器中加密算法声明为native方法，对具体实现进行隐藏。
核型类图：
场景2、加密算法进行参数加密
使用加密算法对请求参数进行加密，可以防止第三方修改参数，例如给赠送优惠卷的接口进行加密，防止用户刷接口给修改优惠券的数量。通过实现filter接口，对所有接口进行参数进行加密校验，这样会一定程度上增加接口的耗时，有时只希望对部分接口进行参数加密，此时可以考试使用切面编程+注解方式，在切面类中对参数进行加密校验，在需要加密校验接口上添加标识注解，同切面类统一处理。
场景3、对会员视频进行加密
用户在对视频路径的获取只有一次，随后在用户和CDN之间建立起视频流传输通道。只对请求参数和请求url进行加密校验，依然无法防止视频分享，因此需要对返回视频流进行加密。
Conclusion
从加密方式上看，场景1和场景2属于单向加密，不要要解析，加密得到的签名只用于安全性校验，场景3为双向加密，需要还原出加密数据。场景1通过设置失效性签名，在一定程度上保证了服务端之处理来自自己客户端请求，但第三方采用非手动方式（如果第三方编写程序，缩短劫持时间）依然可以劫持请求，依然会通过校验，劫持过程中，如果对请求参数进行修改，依然有可能产生不安全行问题，当然可以通过针对具体场景在服务端对参数进行业务校验弥补；场景2有效防止了参数被篡改，不足是，但是第三方可以劫持url，重复对发送该请求，可以通过对接口进行幂等性校验弥补。结合场景1和场景2各自优点，可以对参数进行加密生成签名，同时向签名中加入时间戳控制失效性，可以一定程度上防止url被劫持，并且可以保证参数不被篡改。由于加密方式在客户端也存在在，一旦泄漏，整个加密将完全失效。
可以对场景3中不同视频资源使用不用的密钥进行加密，并且可以对加密服务器下发密钥进行二次加密，增加破解成本。
任何加密算法和技术都存在破密的可能性，根据数据安全要求等级和实现成本，选择合适的方式对数据进行加密。
