RSA加密 - 数据传输过程中的加密和防篡改

1：先说下我遇到的加密场景：

        公司要做一个投资理财的app，涉及到的金额部分比较多，且金额不是太小，所以要求程序的严谨程度较高。另一方面，由于同时要提供 web，android和IOS三个平台的实现，接口的安全性要求特别严格，可以说是到了“没有相信任何外来数据”的程度。因此，在接口的身份、数据合法性验证上，要求特别严格。我没有使用md5或者类md5生成签名的方式，同时也没有使用类似微信的Token方式。这里用到的加密方式是RSA非对称加密，而非前两种的对称加密。

2：加签：

        这里，我借鉴了md5签名的思路，形成一非对称的rsa签名，从而前后端验证数据合法性。

        2.1：转化字符串。由于任何加密算法加密的对象都是字符串，所以，不管何种数据，都需要转换成字符串才能进行加密。当然数据转化成字符串的方式有很多：json_endc，serialize，甚至于，你可以自己组织一种形式，比如：get参数形式。其实这主要取决于前端解析，看他们解析什么形式的数据比较方便。

        2.2：对2.1的字符串加密，获得签名。

3：验签：

        3.1：解签。解密签名，获取用于形成签名的字符串。

        3.2：验签。按照和后端一样的字符串生成方式，生成后的字符串和解签后的字符串比较。从而验证数据的合法性。

4：RSA Keypair 生成的几个问题：

        在生成钥匙对时，特别需要注意的几个问题是：

        4.1：你要生成的钥匙的长度将决定最大可加密数据的长度。当然，也将决定加密、解密的时间长度。

        4.2：个人建议，不要在网上在线生成。虽然其原理其实就是找一对互质的大素数，我们也不确定使用【人家的钥匙】是不是就不安全？但是吧，人嘛，就是不喜欢使用别人的。你可以使用openssl软件，生成钥匙对。

        4.3：不要把非对称的RSA当成对称来用。我意思是：你应该是有两对钥匙，然后交换。一般来说，我们在前端放置的是两把公钥。因为，私钥可以生成公钥。

5：RSA的最大加密长度：

        RSA的最大加密长度是K-11，至于为什么，说起来也汗颜，我也不知道，虽然我的专业是数学吧。。。

        1024     k=128       maxLength=117

        2048     k=256       maxLength=244

6：加密的数据太长怎么办？

        6.1：起初，我的想法是【递归抽样】。假如，我们预测一个数据最长的一个接口是【获取***列表】。这个接口从A表获取数据，每次获取10条。每条包含10个键值对。没对长大概20。那么一条就是200.10条就是2000，加上接口编程添加的状态码，描述，等等。按3000长度来算。抽样的想法是：等长分割成20组，每组取5个字符。凑够100个字符。这样的方式【数据被修改的发现机会】比【直接截取3000长度的前100字符】要高。进而，可以进行多次【抽样】。3000-1500-750-375-184-97.进行5次后，基本可以保证【有很大机会发现数据被修改】。这样的想法，我并没有进行多次的测试。但理论上，5次100组，假设一对键值对的数据长度是20，共有150组，那么这个【机会基本上是66%】。当然【发现的机会】和【抽样次数】是正相关的。个人也有打算把这个想法当做学士学位的毕业论文来研究。

        6.2：与对称加密相结合。使用随机字符串（假设是32位的时间戳的md5值）当做AES、DES的钥匙，对数据进行加密。然后用RSA对钥匙进行加密形成【签】。前端获取数据以后，解签获得AES、DES的钥匙，用钥匙解数据。如果能解到数据，说明数据没有被篡改过，是合法数据。

7：其他：

        7.1：您可能会产生的疑惑，比如：对称（md5）数字签名。Token法。RSA加密原理。数字签名。等，请自行百度。后期我整理出对应的文章后，会在此附上链接。

        7.2：需要demo的话，我这里有php版的。RSA结合DES解决上下行接口的安全性问题

        7.3：在这里有鄙人一篇关于数字签名和token的一篇文章：服务器端数据合法性验证：签名sign和口令token原理