用户级的分布式存储文件系统保护个人隐私

这样的话， SLA 就变成了 SLA1*SLA2 ，风险大很多

直接 AES256 加密传上去不更好？
我就把 vhd 用 Bitlocker 加密传 Dropbox 上

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

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

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

@noli 这个想法，我之前做了一些研究，技术上可行性问题不大，关在在于，大多数用户，不关系数据安全性，只有少数关心，如 1 楼。：）

@openroc

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

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

@noli 确实在欧美，用户比较关心数据安全，关于存储，我原来想分片后，放到 drop 的不同账号，或者 dropbox 、 box 、 googledrive 等，要做的只有对数据冗余分片。我在北京，你在哪里？邮箱联系：我的 id @ gmail.com

@openroc 已用 gmail 勾搭

如果文件本身没有加密，分块之后一样会由 entropy 泄露信息。如果加密了，单一 csp 也没有破解能力。

分块可以提供 (m,n ) 冗余，即只要总共 n 份分块的 m 份即可恢复。这可能是唯一优点。

你并不能提供密码学意义上更好的安全性，同时降低了易用性。

@noli 你分成 n 份，一样有密钥的安全问题
密钥分成 n 份，那还是有个“父密钥 /父密码”（不知道该怎么起名称，这个名称相信大家都明白）的安全问题
最终不就是一把钥匙的安全问题吗

看下这个，基于 blockchain
http://storj.io/

@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 的概率的。所以是以这种方式来提高安全性的。

@noli

> 数据加密存在一个或两个 CSP 那里，然后加密密钥由另外一个 CSP 存储。
> 这样一定是存在单点故障导致整个系统失效的可能性的。

你混淆了“安全”的定义，从安全（ Security ）的角度上说，最终只取决于密码学算法和密钥管理，而多点存储关注的是可靠性（ Reliablity ）问题。虽然中文都叫做“数据安全”，但完全是两码事情。


我强调的是，分块之后你还要不要加密？

- 不加密，毫无安全性（ Security ）可言
- 加密，安全性（ Security ）等同密码学方案


如果你想解决与“隐私”相关的问题，你找错了方向。



另外你对于 entropy 的理解不对，能不能观察到 metadata 并不是决定熵多少的因素。（事实情况是，如果你能观察到 metadata 了，相对于加密的情况来说，前者的熵更低而后者的熵更高。）

http://yurichev.com/blog/entropy/

这里有非常详细的解释， entropy 分析价值比一般认知当中大得多。

你的想法有点意思啊

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

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

@noli

“所有的 CSP 不会同时被攻破”只能保证“数据分块不会同时被第三方获取”，但并不能保证“被获取的单一分块不会泄漏数据”。

所以结论就是，你的分布式设想，依旧要做文件级的加密才行。不加密我就可以说它不安全。

解决“隐私”问题的是加密算法，而不是你的“分布式”方案。如果你做产品这么宣传，那是另外一回事。

==========

一个系统的安全性，是由最健壮的环节决定还是由最薄弱的环节决定？理论上是最健壮的环节，而实际上是最薄弱的环节。

你的设想里有分布式模块和文件级加密模块，那么会存在两种可能：

- 分布式模块安全性更高
- 文件级加密模块安全性更高

前一种情况，你要关心文件级加密算法别被破解了（小概率）；后一种情况，你给一个安全系统增加了薄弱的一环，暴露了更大的攻击面。

从实际应用来看，多数应用都要依赖加密算法作为最后一道屏障，考虑到代码实现，几乎没有任何产品可以比纯加密算法能提供更高的安全性。

==========

你还是动手做一下吧，等你做过就知道哪里有问题了。

bittorrent sync?

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

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

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

----

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

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

@noli
无论你怎么折腾，在密码学算法一样的情况下，安全性是完全一样的。

我们应当把网卡之外的数据视作完全不安全。
当你把数据传输出去的时候，无论你存哪里，分割几份，用了多少躲猫猫技术，都应该视作“可以被人获取”，而且事实上 CSP 确实是可以获取到你的数据。

那最终的安全性就要靠密码学算法来保障。

分两份密钥或者多少份，最终在解密的时候，所有密钥还是集中在一起，这和一份密钥没有什么区别。

至于密钥管理，目前的 USB Key 比你想的分 n 份 要安全得多。

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

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

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

@noli
呵呵
陈老师要是用 TrueCrypt 或者 Mac 自带的 AES 加密，结果跟你这样搞的效果是一样的，除非他的私钥保管不严而且被人逼着说出口令。

我的逻辑是建立在你要把数据传输到公网的情况下。
如果只是私下保存，那当然还有其他提高安全等级的方法。

阿里云和 GCE 确实没什么区别，反正你都不可控。

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

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

其实目前所有基于 blockchain 的分布式技术，都可以用来预防单点失败的情况。
那当然就可以用来存储一些比较重要的文件和信息了。
问题的关键是：去中心化的效率不如中心化的好，所以安全和效率有时候真的是要用户自己来取舍。

我就是做分布式存储的

涉密不上网
楼主你想太多了

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

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

说了这么多，就没有人提到 Threshold Cryptography 吗？

@JamesRuan Threshold Cryptography 有意思。
之前我没听说过这个词，但是貌似把密钥切开几份，合并时才能用的做法，就是这个？

@noli 不完全是，并非简简单单地把密钥切开。

密钥可以分成 N 份，其中任意 m>M 份同时存在的时候才可以解密，生成密钥时 M 和 N 的值是确定的。

mac 下做个加密分片的开源应用。对某些个人用户还是有价值的。至少以前看过的一些相关文章，网盘是个人隐私数据或一些公司机密数据泄露的一个途径。：）

@MuhammadWang Storj is based on blockchain technology and peer-to-peer protocols to provide the most secure, private, and encrypted cloud storage.

@itfanr @MuhammadWang 他们有赞助，而且做的事情确实跟这个 topic 提议做的差不多。已经有点心动了，到底是等着眼睁睁看着他们做，还是自己也来一发呢？ @openroc

@noli 企业级的东东，应该不好做吧

storj