Android 中加密的String：让我们做出更少的失误

     如果你在网上搜索“Android 字符串加密”，估计你可以找到大量的实例代码，比如MD5加密，比如DES加密，这些方式输入的字符串和输出像乱码一样的加密字符常常也是不正确的。加密是个比较棘手的问题，它是很难说从搜索出的代码没有严重的缺陷。

     要正确的使用它，必须了解该算法的性能和代码的安全目标， 也许这些不好的加密代码被发布在网上是可以被接受的，但现在有更好的加密方式让我们不能再接受这些代码。

     谷歌Android字符串的加密有个失误，由于是在谷歌第一主打，该代码已经普遍很多地方，其中包括数百个Github上的项目。

    典型的错误：

   *坏密钥生成：理想情况下，AES密钥应牢固并生成随机。另外，根据不同的使用情况，您可以使用标准的基于密码的方法来生成一个密钥，是强如密码。很多网站建议使用从密码作为种子的随机数生成的字节数。这是不对的。 
   *过时密钥生成的：在2013年，人们认识到，在Android的SecureRandom实现是有缺陷和开发人员需要明确初始化PRNG熵。

   *使用ECB：在Android中AES的默认模式是ECB，其加密每个块是一样的，因此受到的分析和攻击，[ECB的一个例证](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_.28ECB.29)想象你加密了一堆密码：你可以不一定解密密码，没有钥匙，但你可以告诉哪些网站使用相同的密码。更好的方式是CBC，而且该模式已经可以在Android使用了相当长的一段时间。


   *没有诚信：很多人认为AES在创建中具有完整性检查，这个思想是：“如果解密正确，它被人用私钥生成”。实际上，AES CBC允许攻击者修改这个消息。在我们的搜索中，我们没有发现在用AES CBC做诚信检查的一个例子。 

   *不正确第IV：当使用例如CBC模式，随机IV是必需的。这使得与密文稍微复杂一点，因为交易需要保留的（非机密）四周围解密。由于它的棘手，有时人们使用固定的IV，这是经常坏。Android的做一些非常奇怪的事情，如果你不指定IV，你加密的东西，永远也无法解密。

   *弱算法：使用DES或MD5的是有问题的，因为两者的那些算法已被证明是弱并且不应再被使用。

 解决问题：
     使用AES 库构建，提供一个Java AesCbcWithIntegrity类，很方便的添加在Android项目中。 
     特性：
     *简单 一个非常简单的Java类,在大多数或所有版本的Android。类应该易于粘贴到现有的代码库
     * 加密字符串： 它应该加密任意的字符串或字节数组。这意味着它需要有效地处理多个街区(CBC)和部分街区(填充)。序列化、反序列化密文的持之以恒、静脉注射和关键材料使用base64使它容易
     *算法和模式 ：选择AES 128,CBC,PKCS5填充
     *IV Handling： 安全地生成一个随机在每个加密和提供一个简单的类保持IV和密文一起所以他们容易跟踪和存储
     *诚信：添加了或多或少地透明的完整性检查的形式，这是组合键的形式,128位的密钥用于加密和256位用于完整,然后钥匙保存在一起

 [参考](http://tozny.com/blog/encrypting-strings-in-android-lets-make-better-mistakes/)
 [源码和实例](http://download.csdn.net/detail/jackiandroid/9355623)