这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 3596 天前的主题，其中的信息可能已经有所发展或是发生改变。
聊天内容公钥加密传输， 私钥只有接收者有。
即使服务器上也是密文存在。从源头上保证隐私。
jcss拿到硬盘数据肯定傻眼。
简单的说就是tox.im 的移动版。
-> 为什么tox 已经做到了，还要造轮子？
<- tox 没有移动版。
-> 这种东西会有人用吗？
<- 发到v2ex就是看看有没有想用。
即使服务器上也是密文存在。从源头上保证隐私。
jcss拿到硬盘数据肯定傻眼。
简单的说就是tox.im 的移动版。
-> 为什么tox 已经做到了，还要造轮子？
<- tox 没有移动版。
-> 这种东西会有人用吗？
<- 发到v2ex就是看看有没有想用。
 |
1
schezuk 2015-02-24 21:57:22 +08:00
输出不方便转换……输入倒是可以结合输入法……得做个插件hack进客户端里……
另外单纯密文太显眼，拿汉字做密文编码，密文效果类似文章生成器似乎好一点…… |
 |
2
luw2007 OP @schezuk 输入（输入法是个问题，只能暂不考虑， 比如直接使用英文好了）本地加密，然后上传服务器，
服务端存储，可以用其他文字替换， 不过很难变成句子。 输出可以直接二维码扫描解码。或者本地存加密密钥，比如九宫格滑动使用本地密钥。强度比较弱了。 |
 |
7
caomu 2015-02-24 22:43:42 +08:00
@luw2007 我推荐的就是那个排头的 telegram http://chloerei.com/2015/02/05/telegram/
|
 |
8
lrz0lrz 2015-02-24 22:45:49 +08:00
私钥怎么给接受者？
或者说怎么防御中间人攻击？ |
 |
9
max0ne 2015-02-24 23:00:35 +08:00
imessage是不是也是号称端到端加密的?
|
|
10
schezuk 2015-02-24 23:00:38 +08:00
打个比方吧，比如你生成密文是
9ECD9EE6 CA15AB4A A777F53C 532E2623 ……（下略）…… 然后9ECD79E6查表造句，假如你的句子格式是S+V+adj+O 9E在主语表中的词是“我们”，CD在谓语表中的的词是“喜欢”， 9E在定语表中的词是“黑色的”，E6在宾语表中的词是“苹果”。 （9E又出现一次，不过这时候是查定语表，结果不一样） 9ECD79E6就生成“我们喜欢黑色的苹果”，这个是一一对应的，反推成9ECD79E6没有问题。 当然这个算法太粗疏，搭配词上下文都没考虑。其实有好算法的话生成的东西未必不能看 下面的诗来自写诗机http://www.dopoem.com/，确实挺像那回事的 《对着大海 高歌》 没有誓言可表达我的爱意 / 庸俗的歌只崇尚下流 / 我站得很远 神秘地 / 对着大海 高歌 |
 |
12
threezhiwang 2015-02-24 23:04:48 +08:00
@lrz0lrz 应该是如何相信对方提供的公钥
|
|
13
threezhiwang 2015-02-24 23:06:34 +08:00
@schezuk 密码本么，适合一对一的情况
|
|
14
threezhiwang 2015-02-24 23:07:42 +08:00
公钥太慢了，而且不安全
RSA适合协商密钥 防范中间人攻击也是个问题 |
|
15
schezuk 2015-02-24 23:14:57 +08:00
@threezhiwang
公钥加密私钥解密，私钥加密公钥解密，解出乱码代表认证失败。 |
|
16
luw2007 OP @threezhiwang 密钥交换只要解决了就不会有中间人问题。 密钥交换暂时想的是接触交换。或者其他方式交换，不通过聊天软件传播。
|
|
17
luw2007 OP @threezhiwang 伪造数据包， 应该可以洪水攻击，比如c 伪造成其它用户给b发消息， 不过这点应该通过协议可以杜绝。
|
 |
18
JustZht 2015-02-24 23:35:31 +08:00  1
|
|
19
JustZht 2015-02-24 23:37:11 +08:00
具体可以看 [https://wiki.tox.im/Client](https://wiki.tox.im/Client) ...应该是指这个TOX吧...
|
 |
20
9hills 2015-02-24 23:42:42 +08:00 via iPad
|
|
22
luw2007 OP |
 |
23
Eleutherios 2015-02-25 01:39:58 +08:00
好像iMessage也是这个套路吧
号称信息公钥加密传输, 密钥只有接受者有. 问题是公钥交换和验证要怎么办? 这类架构只要不是[面对面]交换公钥, 本质上都还是基于对服务器的信任的. 只要黑了服务器, 完成Man-in-Middle攻击不是不可能的事情. @caomu 我无意发起辩论战, 但是telegram使用的是由其作者[自主研发]的加密方式, 这令我完全不信任telegram. 一个优秀的加密方式之所以优秀 - 是因为即便所有人都能看到源码, 也无法破解它 - 而不是因为没有人能看到源码, 所以不知道怎么破解它 |
|
24
Eleutherios 2015-02-25 01:42:11 +08:00
@threezhiwang 我觉得还是XMPP+OTR+面对面交换公钥比较好...虽然只能传输文字...
WIN/LINUX下有jitsi, iOS下有ChatSecure, Android下应该也有类似物. |
|
25
Eleutherios 2015-02-25 01:48:31 +08:00
@luw2007 唔, 抱歉没看到你后面的回复.
关于接触交换, 你不妨参考下XMPP+OTR的相关运作机制, 包括密钥指纹确认/问题回答什么的. |
 |
26
dndx 2015-02-25 03:05:41 +08:00
iMessage 就是端到端公钥加密，何必造轮子。
|
 |
27
NeoAtlantis 2015-02-25 03:41:44 +08:00
@dndx 但是苹果说了要配合网信办的审查。
私钥如果不在你的机器上呆着，比如被同步到了iCloud，怎么办？ 我反正从硬件上就不信任苹果。 另外我也在开发类似的程序，估计过几天能搞定。 用curve25519的js库实现密钥交换。然后我自己的库有blake2s的实现。 但是按照现有的易用设计，没法避免中间人攻击。当然要攻击可能需要先入侵我的服务器。 要么用证书，但是这样就不易用了。要么类似ZRTP的设计，用WebRTC建立语音/视频信道（以后再说，太难了），然后用语音来核对一段密钥的散列。这样很难伪造。 |
|
28
NeoAtlantis 2015-02-25 03:44:06 +08:00
@schezuk 千万不要自己设计算法。你的设计甚至不能算是“现代密码学”（算是古典密码学）。
|
|
29
dndx 2015-02-25 03:47:22 +08:00
|
 |
30
hljjhb 2015-02-25 03:49:44 +08:00
telegram 有端到端加密的聊天模式 还禁止截屏复制 但是拍照就没办法了
|
|
31
dndx 2015-02-25 03:52:48 +08:00
@NeoAtlantis 理论上来说 iMessage 中苹果想窃取信息只有偷偷更换你的公钥 MITM 。只要 iMessage 服务器还在美国，苹果配合中国网监的可能性几乎没有。NSA 也不是吃素的，苹果要是干这种事很容易会被发现。
如果苹果往服务器发送私钥，这么多人盯着 iMessage ，被发现更是分分钟的事。 |
|
33
NeoAtlantis 2015-02-25 04:01:28 +08:00
@dndx
1. 苹果干啥了我不信。不要相信政策安全“我们能看到你的数据，但是我们保证不外泄”。斯诺登什么的该说的都说了吧。 2. “理论上说理论和实际是一致的。” 3. 苹果是会配合中国网监的。因为苹果的大部分市场在国内。你不能指望公司的良心，几亿的资产和你的隐私比你要哪个？苹果平时不发送，不代表受控情况下不发送。也不代表私钥在本地就加密存放了，也不代表加密私钥的口令到对称密钥的步骤就是安全的（比如PBKDF2的迭代次数不够什么的）。 4. One Time Pad是不能破解，但是它存在的更多是理论价值。是说，如果你能用伪随机序列在一定长度上模拟OTP，那么就是安全的。比如salsa20这样的流密码。（27楼我为啥要提到blake2s，真是迷糊了，我要说的是salsa20）。 |
|
34
NeoAtlantis 2015-02-25 04:04:32 +08:00
@dndx 即使你在美国，也有几种情况：
1. 苹果配合网信办的要求，但是没有透漏你的数据，因为网信办不需要。 2. 苹果配合NSA，将你的数据给了NSA。 3. NSA不一定不把你的隐私透漏给天朝。如果你确实是很有价值的目标，可以拿来交换的话。理论上是能的。 4. 和你联系的人怎么办？ |
|
35
dndx 2015-02-25 04:07:41 +08:00
@NeoAtlantis 如果使用 OTP ，当然不会使用伪随机序列。直接大气噪声生成随机数据，面对面物理交换。一张光盘的 OTP 发消息够用一辈子了。
|
|
36
NeoAtlantis 2015-02-25 04:10:13 +08:00
@dndx 问题是，OTP不实用。OTP要求密钥和明文长度一样长，但是我希望的是，密钥只要安全，不管密文多长都好保存。而且OTP的密钥不便于管理。比如我要聊天，我怎么和对方事先约定那么长的密码本？如果我新认识了一个朋友呢？而且对称加密和认证好像也没法解决数字签名的问题。
|
|
37
NeoAtlantis 2015-02-25 04:12:58 +08:00
@dndx 另外关于随机数发生器的问题：物理产生的真随机数是不可复现的，但是未必是满足良好的随机规律的。我的建议是至少用物理噪声配合数学的算法来让结果的0-1比例是一样的。
|
|
38
dndx 2015-02-25 04:15:32 +08:00
@NeoAtlantis 没有线下的信任，什么加密算法都没用。
就像你不信任苹果的 iMessage 服务器，别人凭什么信任你的服务器不会替换证书？说到底还是得预先交换密钥，任何非去中心化的，需要服务器的服务都看起来很可疑。 聊天产生的数据太少了，100M 的 OTP 够你聊几个月了吧。用一点销毁一点密钥，量子计算机都无法破解。 |
|
39
NeoAtlantis 2015-02-25 04:17:45 +08:00
@dndx 我的回复好像没到你的点子上。伪随机序列，比如我们假设用salsa20获得一个这样的序列，如果能在2^70的长度内无法（在一定的代价——比如计算能力——上）和真随机序列区分，那么我的算法就是安全的。这是论证的一个步骤。这种情况下我就只需要保存128～256个比特的密钥。这样的密钥分发就简单多了，销毁也简单多了（假设我把加密数据存在磁带这样的读起来快写起来慢的设备上了，我为了粉碎文件，也只是需要抹消几遍密钥，而不是把整个介质从头到尾抹消几遍）。
|
|
40
dndx 2015-02-25 04:22:31 +08:00
@NeoAtlantis 如果以后计算机的计算能力大幅提升，那么 salsa20 完全有可能被破解。即使目前广泛使用的 DHE 在计算能力足够的情况下也是可以被破解的。
OTP 如果使用 True Random Number + 可靠的密钥交换 + 用后即焚，可以保证未来无论计算机的计算能力有多强，都无法被破解。 |
|
41
NeoAtlantis 2015-02-25 04:22:54 +08:00
@dndx 不要转移话题。这和人与人的信任是两回事，通信的双方也可以只是两台公司内部的分开的计算机。或者比如，我现在在国外，我要和国内的之前信任的小伙伴联系。我知道对方的语气、长相，但是我和他只能通过互联网联系，而且是马上。
>>> 于是你要我走之前和他交换光盘？ 256比特的密钥量子计算机也无法破解。前提是对称加密算法。量子计算机只能把难度降低到128比特上。 还有你没考虑数字签名的情况。这个必须是非对称算法。比如我要签署我发布的软件。 |
|
42
NeoAtlantis 2015-02-25 04:27:51 +08:00
@dndx
“如果以后计算机的计算能力大幅提升，那么 salsa20 完全有可能被破解。” ——破解对称加密比破解不对称加密难得多。请参考密码学理论。良好设计的比如256比特的算法，在量子计算机下被降低到128比特的强度，但是之后还是暴力破解。目前看来，就算把整个地球上的水都拿来冷却地球上所有的计算机，恐怕也是不够的。 DHE是能破解。这是在量子计算机下不安全的东西。但是post-quantum时代的算法也在研究（就是抗量子计算机的），比如Merkle Signature Scheme（TUDarmstadt研究得很多）这个签名机制，现在稍微改进下基本都能实用了，签名结果长度和RSA差不多（不短，比如要3-4kB），但是很安全。加密方面有NTRU，但是这个我了解的不多了。 我说的这些的安全，是实用的，保证在正确使用的情况下，让你这辈子看不到有人能破出来的。下辈子，也不太可能。 |
|
43
dndx 2015-02-25 04:28:07 +08:00
@NeoAtlantis 256 bit 的密钥现在无法破解，不代表 50 年以后也无法破解。想达到 Information-theoretic security ，也就是你老死都不会被破解，只能使用 OTP。
https://en.wikipedia.org/wiki/Information-theoretic_security That is, it cannot be broken even when the adversary has unlimited computing power. The adversary simply does not have enough information to break the encryption, so these cryptosystems are considered cryptanalytically unbreakable. An encryption protocol that has information-theoretic security does not depend for its effectiveness on unproven assumptions about computational hardness, and such an algorithm is not vulnerable to future developments in computer power such as quantum computing. |
|
44
dndx 2015-02-25 04:30:04 +08:00
@NeoAtlantis 另外签名问题很好搞定。假设你的密钥绝对安全，那么直接加密即可，攻击者发给你伪造的信息，你解出来的也是随机数。
OTP 连重放问题都不会存在，因为密钥永远不会被重用，所以签名也没什么实际意义。 |
|
45
threezhiwang 2015-02-25 04:49:45 +08:00
@schezuk 一般实际应用会把签名结果和明文一起携带，然后双方约定哈希算法
|
|
46
threezhiwang 2015-02-25 04:52:49 +08:00
@9hills RSA系列从理论上讲，没法加密随机数
|
|
47
threezhiwang 2015-02-25 04:56:55 +08:00
@NeoAtlantis 要绝对安全，就要附加一个安全设备
|
|
48
NeoAtlantis 2015-02-25 05:11:21 +08:00
@dndx 我再重复一遍：OTP不实用！！还要我强调几遍？缺少很多有用的特性。
我相信50年之后不能破解，这就够了，50年不够加大长度到100年，我反正不见得能活到那个时候。 签名问题不是你这么搞定的。加密和签名是两回事。 签名完全可以针对明文签名。 我要求的是，我签名了，别人不能伪造。 比如我发一个公告，我需要全世界都能看到，但是我需要没人能伪造我的公告。 我不需要加密，我只需要签名。 比如你运行一个服务器，你要求别人不能假装是你的服务器。 现在的SSL是很简单的，可是如果你偏要用OTP，就只能要求线下每个用户收到你一光盘，每张还得是好几个G的流量。 而且，更糟糕的是，你还得在服务器上储存所有用户的流量！ 反正我是不会这样设计。 顺便吐槽下v2ex的发快封半小时的做法。 ---- @threezhiwang 说的对。我正在搞这个（http://neoatlantis.github.io/topics/commsys.html）：  我打算用一个独立的计算机来负责完成类似GPG的工作。 然后外面的聊天软件，用一个插件向我的独立设备发送offer（“我可以给你递交数据，你要说啥？”） 然后独立设备上可以编辑offer。用户如果觉得在设备上打字麻烦，可以在外面编辑。但是只有设备是被信任的。 对方的聊天软件收到密文之后，送进设备解密或者验证签名。 之后根据设备上可以完成的手动或者自动配置，可以将解密后的东西送出设备（这样的设想是为了让设备可以自动化，比如作为门禁系统的一部分）。 另外我考虑把签名和证书分开。就是证书只是自签名的密钥。 别人的对证书的签名“文档”（类似授权书），和证书附加在一起就算是了。但是不设计单独的一种格式。 |
|
49
NeoAtlantis 2015-02-25 05:38:15 +08:00
顺便补充个在别的哪个网站上的估计思路。
我假设用256比特的对称加密。要暴力破解的话， 假设地球上有100亿人口（=10^10） 每人有100台计算机 每台计算机每个操作的完成时间我按照光速除以一个飞米（10^-15次方米，是一个纳米的的一百万分之一，原子直径相比之下有几百皮米，亦即是原子直径的十万分之一） 每台计算机的这样的操作有100个单元。 每个操作就能进行一次破解的尝试。 于是2^256 / (10^10 * 100 * (3*10^8 / 10^-15) * 100) = 2^131.5 这样的话才能刚刚在1/16秒之内破解一个128比特的加密。 但是破解256比特的加密的话（实际上破解256比特的加密平均下来尝试128比特就应该有一半的概率能碰到了），需要的量可不是线性增长的： 2^256 / 2^131.5 / (86400 * 365) 年，即9.5×10^29年。 我们即使到了这一天，顶多把256比特的加密升级到512比特。 |
 |
50
SharkIng 2015-02-25 05:41:51 +08:00
我是来了解一下这个Tox和那个Telegram有什么区别的？有哪些Tox有的给力功能Telegram没有的么？
|
|
51
threezhiwang 2015-02-25 06:44:31 +08:00
@NeoAtlantis 足够安全的设备树莓派搞不定的 硬件上要防旁路攻击 光照分析 固件层还得考虑权限控制和重放等等等
|
|
52
NeoAtlantis 2015-02-25 06:57:21 +08:00
@threezhiwang 那就得看要求足够到什么程度的安全了，或者说防的是什么人了。我只是要求比一般的好一点。有些东西也是和设计有关的，比如Salsa20就比AES在抵抗测量时间的那种攻击要好一点（Bernstein好像是这么说过）。
|
 |
53
Halry 2015-02-25 07:05:35 +08:00
@Eleutherios telegram已经被爆出来明文在db保存（android），幸好注册了也没用过
|
|
54
schezuk 2015-02-25 07:12:19 +08:00
@NeoAtlantis 不是算法，是说把加密的文字用汉语隐藏，要不然借着QQ/MSN传输太显眼
|
|
55
Halry 2015-02-25 07:14:10 +08:00
看到大家这样说，通过计算机聊天还是太危险了，有必要的还是见面面对面聊，不带手机的那种吧，你看那么多美剧里面的犯罪都是见面聊的
|
|
56
schezuk 2015-02-25 07:19:05 +08:00
@NeoAtlantis 原文比如是“千万不要自己设计算法。”，
（用RSA）加密之后是“9ECD9EE6CA15AB4AA777F53C532E2623”，这谁都知道是密文。 然后封装成汉语“我们喜欢黑色的苹果他们喜欢绿色的鸭梨天上行走沉重的馅饼地上掉下坚硬的香蕉”。 这样人固然知道是加密了的，QQ/MSN的服务器想识别这是密语就得提高自己智能了。 |
|
58
NeoAtlantis 2015-02-25 07:40:10 +08:00
@schezuk soga，这不是加密，是用汉字来编码。不过这样效率没有Base64高（但这未必是缺点）。
要注意避免敏感词出现。不过Base64有时候也更容易，比如 \xf3\xde\xb8 出现某个年份组合就难免了。 一个字符可以代表64比特（在B64编码时），但是两个字符构成一个汉字（至少得这样），就得找4096个汉字（幸好汉语博大精深）。 |
|
59
NeoAtlantis 2015-02-25 07:46:45 +08:00
@Halry 见面了也不能聊，只能用肢体语言（比如眨眼睛或者用手指点对方，摩尔斯电码）。
|
 |
60
geeklian 2015-02-25 07:51:49 +08:00 via iPhone 1
楼上这哥俩干啥的...需要天天防着网信办。
苹果能在中国做生意的大前提，当然是配合审查。 不过估计五块钱的扳手就能解决的问题，用不着去苹果取证。 |
 |
61
hadg 2015-02-25 07:56:30 +08:00
便签加密法秒一切
|
|
62
schezuk 2015-02-25 08:03:13 +08:00
@NeoAtlantis
不但要汉字编码，还要修饰得可读（像写诗机就是可读的） 所以是一字多密，哪个顺口用哪个做编码（词库要回避敏感词） 比如9E作为adj，同时对应“黑色”，“巨大”，“香甜”…… 后面接的是E6“苹果”，那么就要选“香甜”作为9E的编码 语法也不能那么单一，总是S + V + adj + O太显眼了…… 当然这也都是比方……实现“可读”，总不能受这么粗糙的模式限制 |
|
63
Halry 2015-02-25 08:47:54 +08:00
@NeoAtlantis 是呀是呀，还要在个黑暗的地方，没有摄像头的地方，完全屏蔽的地方，卫星也探测不到才行。
android干净的用google的hangout就行，apple就算了吧，apple的文件就在中国境内还用找apple？ |
|
64
9hills 2015-02-25 08:51:23 +08:00 via iPhone
@threezhiwang 多说无益，给你一段gpg加密密文带公钥，你敢接收挑战么
|
 |
65
lucifer9 2015-02-25 08:59:21 +08:00
不妨考虑另外一种思路
嗯，没错，就是以前黑社会的交流方式 |
 |
66
mistyhua 2015-02-25 09:08:04 +08:00
每个客户端一对公私钥，公钥作为用户ID。
然后相互签名鉴定不就行了。。。 还有 RSA 加密又不要证书。。。 考虑性能的话，相互鉴定后，交换一个对称加密的秘钥。数据就用这么加密就好了。 |
|
67
luw2007 OP |
 |
69
zkd8907 2015-02-25 10:17:00 +08:00
歪下楼。。。。
楼上的同学到底做了什么惊天地的事情需要网信办亲自来查 = =||| |
|
70
luw2007 OP @zkd8907 是指我么? 对于你的问题, 我想说,你是猴子请来的救兵吗?
棱镜门一出, 数据安全人人自危. 这里只是探讨如何加密聊天, 给别人说话权利. |
 |
71
mahone3297 2015-02-25 10:45:26 +08:00
lz想做的，也是我想做的。。。思路也大致相同。。。公私钥。。。
|
|
73
luw2007 OP |
|
75
9hills 2015-02-25 11:09:39 +08:00
@yangff 你真能搞定RSA，可以说整个世界都归你所有了。
VPN有RSA SecurlD？对您来说挥挥手啊，公钥算私钥。什么HTTPS，什么U盾简直在您面前就是纸糊的。银行里的钱随便取，什么内网随便进。以后叫您世界之王如何。 |
 |
77
yanyuechuixue 2015-02-25 11:16:11 +08:00 via Android
有种会变成约炮神器的感觉。
|
 |
78
yangff 2015-02-25 11:27:29 +08:00 via Android
@9hills 你想想一份核弹完整的制造流程和实验数据能值多少钱，与此相比只要一些电费就能得到他们是多么简单的事情。
你知道为什么证书都有有效期吗？ 你知道rsa算法为什么安全吗？ 你知道拿rsa做永久加密是多傻逼吗？ |
|
79
9hills 2015-02-25 11:30:20 +08:00
|
|
80
Eleutherios 2015-02-25 11:33:39 +08:00
@NeoAtlantis
我最近开始觉得, 用智能手机就不要太在意隐私. 从底层硬件固件到系统到软件, 后门无所不在. 或者换句话说, 用智能手机的隐藏协议就是你默许了隐私泄露. 至于电脑, Linux系统也只能部分保证软件层面的安全性. 至于WIN和MAC, 请参看上述隐藏协议. 想起之前一个坊间传闻, 说拉登被抓, 就是因为他的一个佣人用了手机打了电话. @geeklian @zkd8907 我以为这已经算是学术类讨论了. 至于网信办要不要查, 爱查不查. 这从来不是问题关键. @SharkIng Telegram从密码学上完全不值得托付信任, 至于开价30万刀跪求一破什么的, 个人认为完全是商业炒作/哗众取宠. Tox则有待安全审查(security audit). @luw2007 棱镜门其实从另一个侧面证明了绝大部分人确实是不注重隐私的. |
|
81
Eleutherios 2015-02-25 11:36:55 +08:00
|
|
82
SharkIng 2015-02-25 12:31:26 +08:00
|
 |
83
fashioncj 2015-02-25 13:03:48 +08:00
之前有在qq上注入一个dll自动加密。。然后。。qq更新了，，
|
 |
84
Draplater 2015-02-25 14:31:37 +08:00
openpgp的邮件加密不就可以了吗
|
|
85
NeoAtlantis 2015-02-25 18:04:49 +08:00 via Android
@Eleutherios 手机确实泄漏啊。大学时军事理论课来的解放军叔叔举过毛子打车臣的栗子。据说苹果手机能通过某个飞机上的设备激活什么的。此外去某些厂子实习时参观车间也要求手机都存在外面，不是关机就行的。
|
 |
86
luyiyuan129 2015-02-25 18:20:30 +08:00
马克
|
 |
87
LMkillme 2015-02-26 10:12:57 +08:00
楼主是看了easy的那个讲座视频么？
|
|
88
luw2007 OP @LMkillme 没有看过. 视频地址是什么?
以前我媳妇是用飞信, 后来被我拉到Gtalk上. 飞信的聊天记录找不到了. 但是Gtalk的聊天记录还在邮箱备份中. 主要Google talk 没有了. 想聊点什么就想到国内jcss有各个厂商的推送接口. 还有明文密码. 瞬间就不想聊了. |
|
89
LMkillme 2015-02-26 11:56:22 +08:00 via iPhone
|
|
90
luw2007 OP 必须不是, 这个想法是看到gtalk 没有了才想到的.
|
 |
91
88080398 2015-05-17 21:56:21 +08:00
现在微信不也是没羞没臊吗
|
|
92
threezhiwang 2015-12-23 18:15:51 +08:00
@9hills 探讨的是系统健壮性
而不是我能不能破某些加密算法 算法选择公开的现代加密算法 没被明确要求放弃使用的就可以保证安全 但是系统的健壮性涉及方面太多 我给你段 SM3 的 HASH 让你推明文，你还不得推到天荒地老去 但是现在不加 salt 的 MD5 就是不安全的 这没争议吧 |
|
93
9hills 2015-12-23 22:06:50 +08:00
@threezhiwang
有谁和你讨论 md5 么？ |
|
94
9hills 2015-12-23 22:07:18 +08:00
@threezhiwang ctrl+f ，硬是没在这个页面找到 md5 关键词。。。
|
|
95
luw2007 OP md5 怎么没法反解密。 只能用来做签名。
|
Select Language