常用开发加密方法

前言

相信大家在开发中都遇到过, 有些隐秘信息需要做加密传输的场景.
A: 你就把 XXX 做一下 base64 加密传过来就行

这些问题相信大家都遇到过, 那么在实际开发中我们应该如何选择加密方法呢?

1249329-dd96e8939723fa03.png

加密
==

这里我就直接抛出来几个加密规则

  • AES对称加密, 双方只有同一个秘钥key
  • RSA非对称加密, 生成一对公私钥.

首先要明确一点, 即使做了加密也不能保证我们的信息就是绝对安全的, 只是尽可能的提升破解难度, 加密算法的实现都是公开的, 所以秘钥如何安全的存储是我们要重点考虑的问题.

关于这两种加密算法大家可以网上查一下原理, 这里我不介绍原理, 只介绍给大家特定场景下如何选择最优的加密规则, 以及一些小 Tips.

AES

对称加密, 很好理解, 生成唯一秘钥key, 双方本别可以用key做加密 / 解密. 是比较常用的加密首段,AES 只是一种加密规则, 具体的加密还有很多种, 目前主流使用的是 AES/GCM.

RSA

非对称加密, 生成一对秘钥,public key/private key,
加解密使用时: public key加密, private key解密.
签名验证时 : private key签名 , public key验签

这里说一下实际案例:

某某公司,2B 的后台支付接口, 突然有一天一个商家反馈为什么我账户里钱都没有了, 通过日志一查发现都是正常操作刷走了. 而某公司并没有办法证明自己的系统是没问题的. 理论上这个接口的key下发给商户, 但是某某公司也是有这个key的, 所以到底是谁泄漏了key又是谁刷走了账户里的钱, 谁也无法证明.

这里我们要想一个问题, 我们要怎么做才能防止出现此类问题后, 商户过来说不是我刷的钱, 寻求赔偿的时候, 拿出证据打发他们?

这个问题就可以利用RSA来解决, 在接入公司生成APP key要求接入方自己生成一对RSA秘钥, 然后讲 public key上传给我们, private key由接入方自己保存, 而我们只需要验证订单中的签名是否是由private key签名的, 而非其他阿猫阿狗签名的订单. 如果出现了上诉问题, 那么说明接入方的private key泄漏与我们无关, 这样我们就能防止接入方抵赖.

完整性校验. 防串改

很多情况下我们需要对数据的完整性做校验, 比如对方发过来一个文件, 我们怎么知道这个问题件就是源文件, 而非被别人恶意拦截串改后的问题?

早些年大家下载程序的时候应该会看到, 当前文件的 md5 值是 XXXXX, 这个就是为了防止文件被修改的存在的. 早期我们都是用md5/sha1来做完整性校验, 后来由sha1升级出现了sha256. 大家可能不知道应该如何选择.

下面是一个经典故事
Google之前公开过两个不同的 PDF, 而它们拥有相同的sha1

1249329-5108ee201e09d804.jpg

两个不同的文件拥有相同sha1值, 这意味着我们本地使用的程序sha1是源文件非串改后的, 但实际上可能早已偷梁换柱. 这是很可怕的.
所以推荐大家在用完整性校验时要使用sha256, 会更安全些.