@mengzhuo 这么巧？我也是，最近在开始做 ceph 优化。

不过你没有看到 4-5 楼就说我想太多，那么你也太没耐性了。
不赚天朝人民的钱还不行吗？

@lhbc 如果以上说的这些你看完了依然觉得和 truecrypt 单机保存是一样的，那么很遗憾我的表达能力不足以让你理解差别在哪里

阿里云和 GCE 不一样的地方在于一个细节。这么说吧，即使你可以以足够快的速度从 GCE 的机房在运行时拆下一个硬盘，那么你在这个硬盘上读取到任意一个用户的数据，跟他传送到网络上的数据，即以用户密钥解密前的数据，都是完全不一样的，但对阿里云来说，则不是。

@lhbc 哈哈，密钥集中在一起的时候（例如在客户端上）怎么解决安全问题，那就不是这个东西要解决的问题啦。这里归根到底是要解决，如果陈老师把艳照上传到这里，那么艳照会不会从这里泄漏。

而且，以你的方式来说的话，任何密码学以外保证数据安全的努力都是无用功了。

可是，这个理解方式不符合现实啊，例如你的数据存在阿里云上跟存在 GCE 上的安全性，肯定就不一样。

@zhuang 当然，作为产品级别的存储，不加一个加密好像也对不起“产品级”这个词 ^-^。

于是，只要按照上面所说提到的，不同数据块以不同密钥加密，那么只要不是加密密钥完全泄漏（例如只获取到了加密密钥的一部分），那么“被获取的单一分块不会泄漏数据” 应该是成立的吧，因为加密密钥被分布在了所有的 CSP 上，要么全部泄漏——在只获取一部分的密钥数据无法推算出密钥其他部分的前提下，而这个前提对于多数对称加密的算法来说是成立的——要么完全等效于没有泄漏。

又所以，这种通过分布式保存密钥的方式，来解决了传统云存储密钥保存和数据的、因为保存单点故障导致系统整体安全性失效的 做法，难道不可以简单归纳为，分布式的方案来解决隐私问题吗？

----

实际情况中，多数需要担心的就是分布式模块中的弱点部分被攻破，成为集中突破的缺口。
考虑到整个分布式存储中所有的节点扮演的功能都是一样的，可以大致上看作每个节点的攻破难度是相当的。那么最大的弱点应该就是在于客户端上了。

当然，使用类似于 CRUSH 之类的算法，来保证单点存储和访问量均衡，那是实现中肯定要解决的问题。

@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 的方式来管理可访问数据的客户端。那么中间人即使截获了全部的数据，数据的安全性还是可以有保障的。

当然这部分我还没想好怎么融合在分布式存储里面。 ：目

@zhuang 你说的很对，在没有提供新的密码学算法的前提下，确实并不能提供密码学意义上更高的安全性。对比现有的解决方法来说，并不是类似 ECC 对比 RSA 这样的提供更多 option 的增加了社会福利。

但是这个东西的好处其实就是针对存在多个 CSP 的实际情况来说的。

设想这样的一个情景，现在同时有两家 CSP 可以为我提供服务，我要存储一些加密了的数据，那我要怎么存储才能保证安全性？

最常见的想法就像 1 楼说的，数据加密存在一个或两个 CSP 那里，然后加密密钥由另外一个 CSP 存储。注意，这个 CSP 可能只是你的手机或者你的电脑。
这样一定是存在单点故障导致整个系统失效的可能性的。

但是，真正的分布式存储，或者说去中心化的存储就是为了消除这种情况而产生的技术。

如果我把两个 CSP 提供的存储， format 成同某个 RAID level 为基础的 fs ，单个 csp 只是一个 block device , 然后把数据分发和冗余 放在这个 fs 上, 那么从 单个 CSP 的角度来看，信息的熵其实是更少的，因为无法观察到例如 file metadata 这样的信息。更不要说组合起来还原出原始信息了。

又因为，从工程上来说，两个 CSP 同时 compromise 的概率是远小于 一个 CSP compromise 的概率的。所以是以这种方式来提高安全性的。

@openroc 已用 gmail 勾搭

@openroc

我想忽悠你一起做这件事。你有研究的话，那我刚好有工程能力，似乎王八对绿豆哦。 XD

并且我相信，国内不关心安全性，可是国外关心啊，愿意为隐私和存储付钱的人不在少数。
反正数据存储是刚需，潜力很大。
是可以一试的，我们可以只提供技术部署方案，譬如提供 SDK 啊，提供服务器软件啊什么的，不直接提供存储。

@lhbc SLA 这个是可以优化的，例如适度的冗余，那么这个 SLA 还可以提高。

对称加密上传保存当然简单又直接，但问题是，密钥保存？如果保存密钥的节点出了问题，譬如你的手机，或者你自己的电脑。

如果利用一致性哈希之类的东西，那么连密钥本身都可以拆成不同的片段来保存，这样安全性还是可以得到保障的。

不敢做的事情最有意思。
我纯属过来插嘴，没有要抬杠的意思，或许某天路上会见到你哦 :P

我虽然看到了全部的结果，并且觉得很厉害。然而我不知道这到底是什么原理，有卵用？
楼主给外行人解说一下这是什么，有什么用？

@binpo 早几天问的话可能会不止有兴趣，现在身不由己了。话说没有私信功能好像还是挺尴尬的，哈哈 @oxygen 请不要介意我借楼回复。

@az402 为什么是坑？
@jy02201949 猫屎咖啡 的 “猫”其实是果子狸吧。我广东人来噶

好熟悉的头像，可惜我不喜欢去北京。
北京找写 Python 的相对其他地方算是容易多了。
产品出来的话求内测求试用。

祝好运。

@benjiam 在没有证书的前提下，是没有办法实现两个节点交互协商密码的。其他的全部是空想。

@benjiam 证书更换协议。