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

这样的话， 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