前言

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

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

未命名文件.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值

v2-400b74c2c97135a713e2e342721bc393_1200x500.jpg

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