真*关于编程随想第三篇
为了严谨，我又去了一次编程随想的博客，我想这是最后一次了！
我只看了他的编程技术相关的博客！通过右侧的分类标签，我只看编程开头的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的文章。现在也不写了
你们就是一群意淫的猴子。明明不学无术，还自己觉得自己特别牛逼。遇到一个人指出错误，就死不承认，还对 我人身攻击。
我就一个应届生，对我网络霸凌！你们不脸红么？我讲了这么多技术，你给我来一句我需要看书学习网络安全？该看病的是你们才对！
