真*关于编程随想第三篇
为了严谨,我又去了一次编程随想的博客,我想这是最后一次了!
我只看了他的编程技术相关的博客!通过右侧的分类标签,我只看编程开头的tag
发现只有2009年一年的内容和编程有关。其他所谓的编程相关的博客,只是一些软件或者网站使用教程,和编程无关,甚至对使用者没有编程能力要求,包括但不限于tor,虚拟机,VeraCrypt等等
然后看到了《扫盲 HTTPS 和 SSL/TLS 协议[3]:密钥交换(密钥协商)算法及其原理》
https://program-think.blogspot.com/2016/09/https-ssl-tls-3.html
这篇文章!
他是往枪口撞了!
这篇文章有很多bug!之所以存在这样的bug,是因为原作者写这类文章的时候,省略了很多关键信息。但是大部分人不是做TLS开发的,所以没有注意到这个省略。最后就网上疯狂转载,变成网上精简版的介绍文章占据了主流。
编程随想,没有学习过TLS,不懂这个是什么东西,去网上搜索,收集到了很多文章。不是自己的终究不是自己的,所以也只是转载了别人的内容。
本来的文章是为了让大家更好的理解,做了简化,合情合理!但是编程随想,明显是出于装逼心态,导致了把错误的东西当成了实际的东西。
重点就是他最后写的 《解决方法——“前向保密/完美正向加密”》 这个段落!
这个段落很明显是原文没有的,编程随想自己加的!但是加入这个段落,却很明显不是因为看了TLS的算法或者规范文档而加入,应该是抄袭的。
我在这里,给编程随想和他的“小粉红”一个月的时间,自己思考下,到底少了什么重要的内容吧!
下个月我来公布答案~
你都可以当专家了,还需要来问我们吗?我就想知道你到底做过什么项目.
你一直攻击编程随想,对你有什么好处?能解决你技能提升的问题吗?那不是说明你编程经验少吗,项目做得少吗,你看了那么多源代码,有何用。你做了多少个项目?
@helloword123 #2
-
我没有攻击任何人
-
攻击与否,是你的主观标准。客观标准只有真话和谎话。如果我说真话了,你应该站我这边,如果我是谎话,你可以举例反驳,而不是疯狗这样咬我。
-
我在阿里一堆代码提交。你可以进到阿里以后自己膜拜。另外i,我写了flutter的video player的windows版本。你死了,我就烧给你。同样的话别老重复了,我回复你好几回了!
对编程随想的建议:麻烦你搜索下《被嘲笑的梦想》,他写的TLS的博客,比你专业太多了。另外,他在文末写了参考文献,而你没有。
如果你可以看完,便嘲笑的梦想,我觉得你就知道自己的tls写的问题有哪些了。
建议你看完以后,修改你的TLS博客内容,并加上参考文献。
再对我和其他人表示公开道歉,你的博客误导了大量小白不说,还导致你的粉丝对我大量的恶意攻击。。。
你也劝劝他们这些疯狗,别来咬人了
另:我会给编程随想反馈你给出的建议
你倒是把你的GitHub拿出来给大家看看,别在这空口白牙。
以下是编程随想原文:
解决方法——“前向保密/完美正向加密”
相比前面这几种密钥协商算法,DH 和 ECDH 是比较能抗“回溯破解”滴。为啥这么说捏?下面解释:
对于 DH 算法,通讯双方握手需要生成各自的私钥(前面提到的整数 a 和 b),然后根据 DH 算法计算得出会话密钥。换句话说,会话密钥依赖于双方的私钥 a 与 b。DH 算法的优势在于——双方的私钥(a & b)是可以【动态生成】滴!
为了对抗“回溯性破解”,可以强制要求双方每次都生成【随机的】私钥。而且每次生成的两个私钥用完就丢弃(销毁)。如此一来,攻击者就难以破解过往的历史数据。DH 算法经过如此改良之后叫做 DHE(追加的字母 E 表示【ephemeral】)。
与 DH 类似,ECDH 也可以做类似的改良,变成 ECDHE,以对抗“回溯破解”。
能够对抗“回溯破解”的密钥交换算法,被称为“前向保密”,洋文叫“forward secrecy”,缩写为 FS。它还有另一个称呼——“完美正向加密”(洋文是“perfect forward secrecy”,缩写为 PFS)。关于这方面的更多介绍,可以参见维基百科(链接在“这里”)。
以下是 知乎原文:
如何理解前向安全性?和完美前向保密(perfect forward secrecy)区别?
作者:SDKany 密码学与信息安全博士生-暨南大学
链接:https://www.zhihu.com/question/45203206/answer/98980606
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
题主所说的“前向安全性”应当是叫做“forward security”。该定义最早是由Mihir Bellare和Sara K. Miner在 CRYPTO’99上提出的关于数字签名的性质[1]。而“perfect forward secrecy”则是由Christoph G. Günther在EUROCRYPT ’89提出的,其最初用于定义会话密钥交换协议的一种安全性[2]。 (Perfect)Forward secrecy的大致意思是:用来产生会话密钥(session key)的长期密钥(long-term key)泄露出去,不会造成之前通讯时使用的会话密钥(session key)的泄露,也就不会暴漏以前的通讯内容。简单的说,当你丢了这个long-term key之后,你以后的行为的安全性无法保证,但是你之前的行为是保证安全的。 之所以Perfect加上括号,是因为这个词蕴含了无条件安全的性质,大部分的forward secrecy方案是无法达到Perfect的。而forward security的保证的是:敌手获取到了你当前的密钥,但是也无法成功伪造一个过去的签名。 简单的说,这两个概念是用在不同的环境中,但是其意图是一样的:保证密钥丢失之前的消息安全性或签名的不可伪造性。 一般而言,满足Forward secrecy或者forward security的公钥环境下的(签名、密钥交换或加密)方案,其公钥是固定的,而密钥则随着时间进行更新。这个更新过程是单向的,因此也就保证了拿到当前的密钥,是无法恢复出以前的密钥,从而保证了“前向安全”。 与之相对应的还有“后向安全( backward secrecy或security)”的概念,不过这个概念研究的比较少,题主有兴趣可以自行查找该概念。参考文献:[1] Bellare, Mihir, and Sara K. Miner. "A forward-secure digital signature scheme." Advances in Cryptology—Crypto’99. Springer Berlin Heidelberg, 1999.[2] Günther, Christoph G. "An identity-based key-exchange protocol." Advances in Cryptology—Eurocrypt’89. Springer Berlin Heidelberg, 1989.
编辑于 2016-05-04
很明显,编程随想把 “forward security”和“perfect forward secrecy” 两个单词混在一起说了!
这篇知乎回答的作者,是网络安全研究的博士。
很明显,编程随想没有受过专业的教育,也没有系统学习过网络安全。
他只是看了几篇科普文章,然后就自己怎么理解怎么说了。但是又没有标注自己看了哪篇文章或者博客,所以这个行为是抄袭!
再看看知乎这位,哪怕回答这么有理有据,仍然标注脚标,还给出了文献引用。
还有上面的“被嘲笑的梦想”的博客,每篇都文章末尾标注了文献引用。
再去看看知乎专栏,掘金,infoQ。。。
我相信,是不是专业人士,是不是程序员,看他的职业操守就知道了。
为什么其他人写文章可以专业,可以有职业习惯。而编程随想没有?很明显他没有在平时生活中,和我们一样,有写论文的习惯
同时,也证明了,他没有做到所谓的时间管理,仅仅是花点时间看看微信公众号,看点皮毛就班门弄斧,误人子弟,,,
要想真的做到科普,自然应该要多学习,而不是看点科普文章,抄袭转载,再自己胡说八道
再来是“回溯破解”
讲的是,主密钥的私钥泄露了,可以破解以前的密文,知道明文内容。
讲的简单点吧。A是服务器,它有一个证书X509,里面存了服务器的公钥C1,自己有一个私钥P1
但是每次交互的时候,ECDHE都会产生一个公钥C2和私钥P2,公共密钥,是用P2交互出来的,而不是P1
所以,哪怕P1私钥泄露了,攻击者也无法得知当时的P2是多少,也就无法知道当时的明文。
所以,抗回溯破解的关键在于 , 主密钥和会话密钥的无关联性。主密钥泄露了不影响会话密钥的安全性。
而不是单纯的说一句“每次会话密钥不同”这么简单。
再有,用ECDHE得到的,也不叫会话密钥,应该叫”伪随机数”。这个在TLS规范里应该叫 pre master key
通过KDF类算法,得到最终的会话密钥。
过去,TLS1.2版本,使用的KDF算法,叫PRF。
但是TLS1.3版本,使用了 HKDF算法。这个是TLS1.3非常大的改变,编程随想没有说到!
另外,把ECDHE协商出来的key,直接要会话密钥是不正确的!
再有,哪怕用prf算法得到了会话密钥,也不会直接用这个密钥!而是再用hkdf算法,得到一次服务器发给客户端的,和客户端发给服务器的,,,
ECDHE得到了密钥 C1
根据C1作为随机种子,再用HKDF得到了会话密钥C2【label 为 Label1】
根据C2作为随机种子,再用HKDF得到了服务器发给客户端的密钥C3【label 为 Label2】
根据C2作为随机种子,再用HKDF得到了客户端发给服务器的密钥C4【label 为 Label3】
具体label,我懒得查了,,,
再有,TLS1.3,对密钥的的要求非常高,不仅仅对app层的加密两个方向分别设置了不同的密钥!
还对不同阶段要求生成不同的密钥,包括early data,handshake,application
也就是,不同阶段,不同方向,得到了好多密钥!
不但如此,还可以在传输的时候,要求更换密钥。UPdate request!
很明显,编程随想,对会话密钥的理解有非常大的误导性,,,
省略了很多很多内容。
如果只是谈ECDHE算法本身,没有任何问题。但是如果说这个就是会话密钥,问题就很大了!
还有,编程随想经常提到VeraCrypt,但是他估计不知道VC的密钥也是用KDF算法生成的。
如果他知道KDF算法,自然就会写个文章介绍KDF算法了。都十多年了,只字不提,,,
都提到了ECDHE了,哪怕提一嘴“这个密钥以后根据KDF算法派生”也就可以点到为止。
但是不管是TLS的密钥交换,还是介绍VeraCrypt,都不去提及KDF算法,为什么呢?
我觉得,大家看完以后,应该心里有数了!
到底是编程随想知道有这些内容,不提!
or
还是编程随想不知道有这些东西,所以不提!
额外补充:你们老说编程随想,现在做管理了,所以编程内容少了。我觉得很诡异!
程序员做管理,都是慢慢升的吧?没有一次性当总裁的。
那么自然会知道什么叫矩阵经理,什么叫矩阵式管理。
都普及ECDHE这么专业的东西了,项目管理的三大模式【项目,职能,矩阵】,更加贴近自己工作的东西不提么?
普及这个也泄露你个人隐私么?
还有,品葱站长,自己写的品葱(开源),至今都安全无恙。你为什么不自己开一个博客网站呢?
再有,V2ray的作者,自己开源了V2ray,至今也没有听说被喝茶,你说的代码指纹呢?
这些答案,我估计我是看不到了,,,
这一个月,我被编程随想的“狂热粉丝”疯狂攻击。
明明只是技术讨论,偏偏要对我进行人身攻击,,,所以,为了眼不见心不烦。我就换个地方玩了!
我现在正式宣布回归“看雪论坛”!
感谢管理员没有把我发的贴子移到水区,没有折叠我的回复~
谢谢!
编程随想只是做安全方面的普及工作,受众对象是,在安全方面是小白的翻墙反贼。对于普通翻墙者而言,仅仅需要掌握了Tor+vpn技术,就能很好的保护自己的安全。编程随想在更广的技术话题上,只是开阔眼界罢了。真正需要研究安全问题的特殊群体,coursera不香吗?Stanford不香吗?真正的安全技术专家,都是通过书本学来的,而不是看看一两个网页。所以觉得你挺魔怔的。还看雪,我还看雨呢。真想搞技术,老老实实看书才是正道,永远别把只把一方当做权威。那样你永远会走歪路的。
@再看看 #16 我觉得,我好心帮你们纠正错误,你们却现在反咬我,真的是狗咬吕洞宾!
从前有个白帽,他给“世纪佳缘”提了一个漏洞,然后“乌云”没有了!
现在的你们,何尝不是一个“世纪佳缘”?
估计你们这些智障,都不知道乌云是什么!
只是要求编程随想在博客里,注明“文献引用”,居然就是人身攻击,真的是天下最大的笑话了!
你们和粉红一样,G点在哪里,让人很纳闷!
再有,明明只是剽窃抄袭转载,到你们这里,就是科普了。是不是你们疯了?
我的技术功底有多深,你应该用脑子思考下。如果我不是系统学习了TLS,如何可以一看他的博客,就能和机关枪一样,随便抓到漏洞,还写这么多?我不是专家,都可以抓到这么多漏洞,编程随想自己的安全常识都已经堪忧了吧?
本来打算再写一篇,关于编程随想讨论alphago的文章。现在也不写了
你们就是一群意淫的猴子。明明不学无术,还自己觉得自己特别牛逼。遇到一个人指出错误,就死不承认,还对 我人身攻击。
我就一个应届生,对我网络霸凌!你们不脸红么?我讲了这么多技术,你给我来一句我需要看书学习网络安全?该看病的是你们才对!