这是我参与8月更文挑战的第8天，活动详情查看：8月更文挑战
数据加密传输
下面对传输数据进行加密解密
- 方案一：直接对io流进行加密解密
客户端变更如下：
while (((len = fileOutStream.read(buffer)) != -1)) {
outStream.write(DesUtil.encrypt(buffer) ,0, len); // 对字节数组进行加密
}
服务端变更代码：
while ((len = inStream.read(buffer)) != -1) {
fileOutStream.write(DesUtil.decrypt(buffer), 0, len); // 对字节数组进行解密
}
执行代码后，服务端解密时会报如下异常：
javax.crypto.BadPaddingException: pad block corrupted
猜测错误原因是加密过程会对数据进行填充处理，然后在io流传输的过程中，数据有丢包现象发生，所以解密会报异常。
加密后的结果是字节数组，这些被加密后的字节在码表（例如UTF-8 码表）上找不到对应字符，会出现乱码，当乱码字符串再次转换为字节数组时，长度会变化，导致解密失败，所以转换后的数据是不安全的。
于是尝试了使用NOPadding填充模式，这样虽然可以成功解密，测试中发现对于一般文件，如.txt文件可以正常显示内容，但是.apk等文件则会有解析包出现异常等错误提示。
- 方案二：使用字符流
使用Base64 对字节数组进行编码，任何字节都能映射成对应的Base64 字符，之后能恢复到字节数组，利于加密后数据的保存于传输，所以转换是安全的。同样，字节数组转换成16 进制字符串也是安全的。
由于客户端从输入文件中读取的是字节流，需要先将字节流转换成字符流，而服务端接收到字符流后需要先转换成字节流，再将其写入到文件。测试中发现可以对字符流成功解密，但是将文件转化成字符流进行传输是个连续的过程，而文件的写出和写入又比较繁琐，操作过程中会出现很多问题。
- 方案三：使用CipherInputStream、CipherOutputStream
使用过程中发现只有当CipherOutputStream流close时，CipherInputStream才会接收到数据，显然这个方案也只好pass掉。
- 方案四：使用SSLSocket
在Android上使用SSLSocket的会稍显复杂，首先客户端和服务端需要生成秘钥和证书。生成方法可以参考这篇。Android证书的格式还必须是bks格式（Java使用jks格式）。一般来说，我们使用jdk的keytool只能生成jks的证书库，如果生成bks的则需要下载BouncyCastle库。具体方法可以参考这里
服务端的代码参考：blog.sina.com.cn/s/blog_792c…
客户端的代码参考：blog.sina.com.cn/s/blog_792c…
当以上所有的一切都准备完毕后，如果在Android6.0以上使用你会悲催的发现下面这个异常：
javax.net.ssl.SSLHandshakeException: Handshake failed
异常原因：SSLSocket签名算法默认为DSA，Android6.0（API 23）以后KeyStore发生更改，不再支持DSA，但仍支持ECDSA。
所以如果想在Android6.0以上使用SSLSocket，需要将DSA改成ECDSA...org感觉坑越入越深看不到底呀...于是决定换个思路来解决socket加密这个问题。既然对文件边传边加密解密不好使，那能不能客户端传输文件前先对文件进行加密，然后进行传输，服务端成功接收文件后，再对文件进行解密呢。于是就有了下面这个方案。
