是否有算法保护已知内容的数据（以秘密为例）
xsser (十根阳具有长短!!) | 2014-06-30 21:19
我们知道手机号码是已知的，秘密借助手机号标识身份，那么当相关数据出现泄漏的时候是否还能够保护好用户的身份信息呢？或者有什么算法能保护呢？
RT
各种吐槽：
1#
小胖子 (全世界背叛我又怎样，有z7y就足够了。) | 2014-06-30 21:21
坚决不要妹子注册各种东西，哼！
2#
无敌L.t.H (:端异是都乳贫持支Ѿ乳巨是须必神肉) | 2014-06-30 22:33
如果算法结果是一一对应的那也能撞出来吧……
3#
ling (对方正在浏览色情网站.) | 2014-06-30 22:47
@无敌L.t.H 这个思路好，撞
4#
Lucien | 2014-06-30 23:27
保护不了的。得到密码后在其他手机登陆就能看到所发的秘密
5#
小森森 | 2014-06-30 23:28
如果只是想作唯一标识符的话，似乎加比较长的随机盐再哈希就比较靠谱了……
6#
RedFree (1:1 1-1-1112 |※(器杀制自) | 2014-06-30 23:29
使用类似des/3des的key加密机制。要让泄露的数据对于第三者来说是一堆垃圾，但站点用户可解读。
没明白楼主想干嘛～
7#
漂流瓶 (1111111111111111111111111) | 2014-06-30 23:42
@RedFree 源码搞掉key不就泄露了··
8#
RedFree (1:1 1-1-1112 |※(器杀制自) | 2014-06-30 23:52
@漂流瓶 key以用户密码经不可逆算法生成，用户登录时放在cookie中。网站存用户密码加盐hash加大密码被破难度。这样相当于key只在用户手中。
9#
elysier (屌丝何苦呢) | 2014-06-30 23:59
研究僧老教授们整天都在搞这些，就不需要我们操心了（虽然他们的研究不知道得过多少年才能应用到现实中)。General Secret Sharing（广义秘密） 英文好你就看了，我又不拦你。
10#
漂流瓶 (1111111111111111111111111) | 2014-07-01 00:11
@RedFree 用户忘记密码呢？
11#
李白 | 2014-07-01 00:44
不以公开信息做为唯一标识符。就拿手机号来说，比如借助手机号标识身份的时候还要比较IMEI？
12#
豆子 | 2014-07-01 00:50
手机号加密做成唯一hash？获取手机号进行比对
13#
Michael | 2014-07-01 03:13
@豆子 一个强大的hash应该可行。Hash单独储存在一个独立的数据库，用其他唯一标示符与储存内容的数据库进行关联。知乎的匿名用户回答纪录似乎就是这么做的，并确保员工不能同时拥有这两个数据库的访问权限，可以进一步降低泄漏的可能性。
14#
Mr.x | 2014-07-01 08:53
搜索safenet
15#
xsjswt | 2014-07-01 09:12
一看就知道楼主连基本的密码学常识都没有
16#
xsjswt | 2014-07-01 09:23
任何可逆的加密算法，其保护秘密的原理在于把一个不容易保管的大秘密（明文），替换成一个容易保管的小秘密（密钥）。
在这个基础上，一般的加密数据丢失问题不大。
至于你说用户身份被泄露的事情，这个问题早已超出加密的范畴。
但是，注意这个但是
还是属于密码学的范畴内
密码学里有一种“零知识验证”。数学上也许简单，也许复杂，但是我本人数学很傻逼，所以无法和你描述出原理上是为什么。
但是，这个“零知识验证”的作用就是，在不暴露我持有的信息的前提下，可以向任何人验证，我确实持有此信息。
某科普书上给出的形象的比喻：
我要证明我在一个有两个出口的洞里面，不需要允许你进到洞里面来看到我
我只需要按照你的要求，从标号为1或者为2的洞里面发出信号
这样反复让洞外的能能够已任意高的精度证明我至少能控制洞里面的信号发射器
如果我没有理解错，撸主要找的就是这样一个场景
如果是，请自行参考某科普书
17#
xsjswt | 2014-07-01 09:25
百度百科：零知识证明
18#
Azreal (www.cloudgen.cn) | 2014-07-01 09:48
求来个无密的裤子URL 我们来研究一下
19#
P w | 2014-07-01 09:59
其实，还是要看黑客能不能接触到你的加密算法那块的程序，或者说代码。
20#
livers (如梦似幻) | 2014-07-01 10:03
@xsjswt 十分赞同
21#
xiaolan | 2014-07-01 11:57
我觉得可以利用内部API来进行加密操作
流程图如下：
（需保证加密专属服务器的绝对安全性）
22#
Anonymous (园长是傻逼) | 2014-07-01 12:01
@小胖子 倪什么什么什么。。。哈哈哈哈
23#
xsser (十根阳具有长短!!) | 2014-07-01 12:07
@xiaolan （需保证加密专属服务器的绝对安全性） 这句话不成立啊
24#
乌云 ()ޝ () | 2014-07-01 12:31
@xsjswt @xsser 保证加密算法不被简单推测出来即可，比如自定义一个MD5算法。这样，只要没法简简单单获得加密方式，就算知道明文和密文也是没法推断出来的。xsjswt 的说法非常正确。。。
25#
xiaolan | 2014-07-01 12:36
@xsser
除非能发明出一种算法：在公开算法的条件下，无法通过生成彩虹表的方式跑出密码，并且每次加密所得的结果是一样的。
不过感觉几乎无法，就像
^@*&*#%^@&(#^*^%*@&^&(& = 123456
在知道^@*&*#%^@&(#^*^%*@&^&(& = 123456的条件下，如何使^@*&*#%^@&(#^*^%*@&^&(&不等于123456
除非是^@*&*#%^@&(#^*^%*@&^&(& = 123456 且 ^@*&*#%^@&(#^*^%*@&^&(& = 654321, 也就是一个迷文代表两个明文，但这样算法就不实用了,碰撞率太高.....
26#
摸了你 (叹路走三千，抵不过流年。) | 2014-07-01 14:11
@xsser
1、salt=sha256(random())
2、数据库存 sha256(salt+手机号)
这个能破么？
27#
摸了你 (叹路走三千，抵不过流年。) | 2014-07-01 14:14
如果提高难度的话，我们给hash加个checksum，你碰撞的机率是不是就更小了...
28#
小胖胖要减肥 | 2014-07-01 14:24
还是一个成本问题，手机号这个你再怎么不可逆都可以拿到salt和算法反推，关键是到底数据价值多大
29#
炯炯虾 | 2014-07-01 14:49
你能先破解再说吧
30#
ppt (maodun.github.io)(|nuf rof gnikcah|) | 2014-07-01 15:13
根据密文要能得到明文，所以算法必须可逆，只能从密钥的安全性来考虑。比如将密钥拆分为七颗龙珠分开保管。
31#
xiaolan | 2014-07-01 19:32
上午的时候写了个paper来交流这个，没被通过，被建议来zone讨论。
原文如下：
目前市面上绝大多数以匹配通讯录找联系人的app都仅对手机号等可识别的特征采用了单次散列算法，如下图
根据一些新闻报道，部分应用的加密是在服务器中完成的，并且使用明文传输，这样在恶劣的网络环境下将可能导致用户的整个通讯录被泄漏。即使在传输过程中使用了SSL等手段防止数据被第三方截获，在极端情况下（如WEB服务器/数据库服务器被攻破），仍然会导致数据被解析出来
这样看起来很安全，但是不要忘了。手机号为11位纯数字，目前计算机的计算能力已经很强，如果按照服务器中预设的加密算法来生成对应列表，也不是一件麻烦事。如果服务器的算法被拖，对应列表被拖，这样的“加密”就变成了透明。
那么如何反制这种攻击呢？可以采用专用加密服务器的方式。
将客户端传过来的明文数据在加密专属服务器中进行各种混乱的运算，使攻击者在无法攻破加密专属服务器的情况下不可能知道加密算法，这样即使拖了web/数据库服务器，也无法根据密文手机号解析出明文。不过前提是加密专属服务器的绝对安全。
虽然需要保证这个专用服务器的安全，但是其难度也比保护web/数据库服务器小不少，毕竟加密专属服务器在配置好之后甚至不需要开启远程管理端口，仅开放一个端口即可（80/443等）。仅需要执行几行动态脚本并完成运算。这样攻击者即使拿到了内网，面对一个没有管理端口，web服务只有一个页面的服务器也是无可奈何。而且即使攻击者尝试对加密服务器跑11位数字，其难度也比放到本机慢慢跑要大，因为面对一个负责的管理者，应该很快就会发现这个专属服务器的异常流量吧～
P.S.如果有更好的方案，欢迎来交流。
32#
xsser (十根阳具有长短!!) | 2014-07-01 19:34
@xiaolan 最大程度降低风险也只能这样了
33#
乌云 ()ޝ () | 2014-07-01 22:00
这样也只是保证加密算法不被得到。。。我觉得最核心还是保证加密算法的非易知性。
34#
v_dature | 2014-07-02 21:49
hash那个本来是比较靠谱的，但是关联的是手机号就不靠谱了。。。
35#
E7LE | 2014-07-03 10:18
我竟然看完了！！
36#
insight-labs (Root Yourself in Success) | 2014-07-03 10:21
http://en.wikipedia.org/wiki/Homomorphic_encryption
37#
船长 (船长哥哥博客http://www.z5it.com) | 2014-07-04 15:04
我竟然也看完了
38#
ヤ深蓝T透 | 2014-07-06 00:17
我竟然给看完了
39#
包包 | 2014-07-06 04:21
能不能这么解决呢？似乎你要打造一个XX，就是要保护用户的手机发出的信号的秘密？
我的想法是：分时段，用不同的加密方法。比如：0-6点，就让app提供sha1加密，6-12，提供md5；12-18，提供ads？然后剩下的时间，使用其他的加密方法？但是这些是要封装到app中，app的的源码，如果能够加密，或者说，就是如果分解app，便进行app自毁。不知道这样的方法，行不行？
40#
redcar | 2014-07-07 18:18
能想到的最简单的办法是在客户端用用户口令P对手机号N做加密计算生成密文E=encrypt（N，P），服务用密文E或者其hash指H=hash（E）作为身份标记。这样即使获得H，想要获得N，攻击的难度等价于攻击用户口令。
41#
xsjswt | 2014-07-07 18:52
有办法，不对称加密。但是对服务器的磁盘空间要求比较高。
1. 服务器保持朋友关系表
2. 每个手机为有自己的公钥私钥对
a. 当用户发秘密
1. 服务器生成一个足够长的id，用用户的公钥加密
2. 用户用私钥解密,向服务器展示此ID
3. 用户以此ID为凭据，一次性推送消息到所有的好友。
也就是说，此步骤之后，服务器可以销毁此ID与手机号的关联关系
4. 用户自己keep住这个id
也就是说，换手机后无法管理自己发送过的秘密
b. 当用户需要管理自己发的秘密
凭a里面，向服务器展示只在本地保存的ID来管理自己发的秘密
42#
xsjswt | 2014-07-07 18:54
当然，这个方法是已损害用户体验为前提的
43#
Comer | 2014-07-07 21:24
LS说的没错，非对称加密吧。对称加密遭破啊！！！
44#
Comer | 2014-07-07 21:29
补充：建议给xiaolan xsjswt俩位靠谱的分析和技术引导加个分吧 @xsser