@
zhuang 说实话，我的理论研究水平并不高，应该看不懂给你给我的那个连接的内容。
但我没有理解错你说的 securtiy 的意思，我上面说的单点故障，说的就是单点在密码学上的安全性无法保证，导致系统安全性被破坏的意思。
下面我提出针对你的 “ security ” 的疑问给出的回答，或许你可以进一步提示我漏洞在哪里？或者提出一个具体的方法？因为我没办法针对一个“理论”而不是一个“算法”提出自己的回应。
@
lhbc 我先归纳一下我怎么理解你（们）的意思。你的想法其实是从最终存储步骤来反推整个安全体系的，对吗？
你的意思是说，譬如某 A 君想要在我所提出的这个分布式文件系统中存储一些东西，尤其是我需要存储一个对所有文件加解密有重要影响的密钥（不管是私钥还是对称解密的密钥不影响这个问题的讨论）的时候，这个安全性会失效，因为：
一，如果我要把这个密钥以 *不*加*密* 的方式，切分成 n 份分别存放在不同的 CSP 之上。那么存在的风险就是：
1 ）这 n 个 CSP 都妥协了，被攻破了，并且联合起来还原出数据……不予讨论，因为这样的情况下完全没有安全可言，什么措施都白搭。
2 ）有一个强大的中间人，或者有一个冒充者分别从这 n 个 CSP 中， 以 CSP 以为合法的方式拿到了这个密钥的数据。简单来说就是，中间人可以完全截获信道中通过的信息。这样什么安全也是白搭的
但是，总的来说，即使是以不加密的方式，总体的安全性仍然是有保障的，起码等同于 n 个 CSP 同时被攻克，或者 n 条通信信道同时泄密 的概率。因为这个数据安全性肯定高于 一个 CSP 的安全性。
我们已经知道，不加密存储的安全几乎等价于所有的 CSP 都 compromise 的可能性，那么进一步，
二，如果我要把这个密钥以加密的方式来存储。那么问题来了，怎么保存加密这个 “密钥的密钥” ？是不是正如 @
zhuang 在 11 楼所说的那样，“安全性” 等同于加密所用的密码学方案？
其实这是一个想当然而产生的伪问题，想当然的地方在于：
1 ）我们真保存“一个”密钥吗？不是的，既然选择了多个 CSP ，我们可以让存储在不同 CSP 上的由同一份数据分拆而来的不同部分，分别使用不同的密钥；然后把某个 CSP 上使用的密钥拆开放在其他不同的 CSP 上来存储。当这些数据，同时汇聚在一起的时候（例如在客户端上），才可以使用解密算法揭开。
这样虽在形式上等同于不加密地存储了密钥，但从工程实现上的难度上来说，除非所有的 CSP 都被攻破，否则任意一份数据被泄漏的可能性，大约等于没有密码的情况下攻破解密的难度。
不过这样依然防止不了超强中间人攻击。为此，我们还需要完成第二重保障。
2 ）与同一台机器上的 app 和 fs 之间的关系不一样，分布式文件存储的客户端和服务端并不在同一台机器上，因此使用公钥系统是可能的。有了公钥系统，我们就可以以 token 的方式来管理可访问数据的客户端。那么中间人即使截获了全部的数据，数据的安全性还是可以有保障的。
当然这部分我还没想好怎么融合在分布式存储里面。 ：目