-
实现了简易版的TLS功能(handshake选择RSA加密)，云服务器有私钥，客户端能做证书认证，能保证防止第三人攻击，理解Generate_Key过程为什么需要三个伪随机数。
-
实现了多方协商密钥，加密文件云存储且云平台不可解密加密文件。
==组密钥实现思路：==
- 客户端每个客户生成一对RSA公私钥，初始时生成唯一一个伪随机数，将自己公钥存放在服务器端。
- 客户端用其他所有用户的公钥加密自己的伪随机数存放在服务器端(可以实现多用户不必同时在线)
- 当用户C想建立一个只能ABC访问的组文件夹时,C先向服务器请求A用C公钥加密的A的伪随机数，同理，请求B用C公钥加密的伪随机数。接收所有其他用户用公钥C加密的自己的随机数后，C用自己私钥进行解密，这样C就获得了ABC的所有位伪随机数。
- 服务器端在确定C收到所有该组内其他用户用公钥C加密的伪随机数后，生成一个伪随机数发送给C，服务器端存储用户组ID、服务器生成的该组对应的伪随机数。
- 客户端C此时接收到的有：ABC的伪随机数和服务器端分配给这个组的伪随机数。此时利用这四个伪随机数通过Generate_Key函数C生成一个组密钥。该Generate_Key函数是类似于MD5的散列函数，在确定输入的情况下输出是唯一的。这样建立组的用户C就得到了这个组的组密钥，文件上传到组内用组密钥加密，下载用组密钥解密。
- 下面讨论AB如何不通过与C通信获取组密钥的过程(以A为例)：
- A上线后，首先可以通过服务器知道自己加入的ABC这个组有哪些成员，然后向服务器请求BC用A的公钥加密的各自的伪随机数和该组对应的服务器生成的伪随机数，A用私钥解密BC用A公钥加密的伪随机数，这样A就知道了ABC和服务端生成的伪随机数，用这四个伪随机数通过Generate_Key函数生成同一个组密钥。
==Tips:为什么服务器要存其他所有用户的公钥以及每个用户用其他所有用户公钥加密后的内容==
由于某个用户创建组的过程中其他用户不一定全部在线，服务器起到确保组内某一方不在线的情况下也可以通过服务器端存放公钥信息和公钥加密后的伪随机数间接地参与到组密钥的生成。
==Tips:为什么服务器端也要生成一个伪随机数，而不是通过ABC三人生成的伪随机数放入Generate_Key来生成组密钥，服务器生成的伪随机数作用是什么呢？==
考虑到ABC在生成组密钥的过程中其实是平权的，也就是说即使是组创建者C，他所获得的组密钥信息和AB是一样的，就是说ABC此时已经知道了ABC对应的伪随机数。那么我们考虑一种情况：如果AB要单独创建一个组，那么如果没有服务器的伪随机数参与，那么通过Generate_Key函数C也可以加入到AB这个组中，就无法实现在ABC组的基础上单独创建AB组这个需求。
下面考虑服务器基于每个组生成伪随机数的作用：在ABC确定伪随机数的情况下，服务器端生成一个唯一的伪随机数与组绑定。即使C知道AB对应的伪随机数，但是C不知道服务器针对AB这个组生成的伪随机数，也是无法加入AB这个组中的。
Summary:
该组密钥生成机制通过第三方服务器端实现了组内成员密钥共享，同时服务器端无法获知最终生成的组密钥。