真*关于编程随想第三篇

SeVen
登入後回覆
  • 张怀义

    为了严谨，我又去了一次编程随想的博客，我想这是最后一次了！

    我只看了他的编程技术相关的博客！通过右侧的分类标签，我只看编程开头的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博客内容，并加上参考文献。

    再对我和其他人表示公开道歉，你的博客误导了大量小白不说，还导致你的粉丝对我大量的恶意攻击。。。

    你也劝劝他们这些疯狗，别来咬人了

    张怀义

    @再看看 #16 我觉得，我好心帮你们纠正错误，你们却现在反咬我，真的是狗咬吕洞宾！

    从前有个白帽，他给“世纪佳缘”提了一个漏洞，然后“乌云”没有了！

    现在的你们，何尝不是一个“世纪佳缘”？

    估计你们这些智障，都不知道乌云是什么！

    只是要求编程随想在博客里，注明“文献引用”，居然就是人身攻击，真的是天下最大的笑话了！

    你们和粉红一样，G点在哪里，让人很纳闷！

    再有，明明只是剽窃抄袭转载，到你们这里，就是科普了。是不是你们疯了？

    我的技术功底有多深，你应该用脑子思考下。如果我不是系统学习了TLS，如何可以一看他的博客，就能和机关枪一样，随便抓到漏洞，还写这么多？我不是专家，都可以抓到这么多漏洞，编程随想自己的安全常识都已经堪忧了吧？

    本来打算再写一篇，关于编程随想讨论alphago的文章。现在也不写了

    你们就是一群意淫的猴子。明明不学无术，还自己觉得自己特别牛逼。遇到一个人指出错误，就死不承认，还对 我人身攻击。

    我就一个应届生，对我网络霸凌！你们不脸红么？我讲了这么多技术，你给我来一句我需要看书学习网络安全？该看病的是你们才对！

    @ycmp #5

    我觉得，有必要让编程随想叫你们怎么使用Google

    https://halfrost.com/https_tls1-2_handshake/

    https://halfrost.com/https_tls1-3_handshake/

    https://halfrost.com/https-key-cipher/

    你可以看看其他人，如何和疯狗一样，咬我了一个多月了，，，

    完全不讲道理，上来就是咬人。明明和他们讲道理，他们就是喜欢咬人，，，

    以下是编程随想原文：

    解决方法——“前向保密/完美正向加密”

    相比前面这几种密钥协商算法，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，至今也没有听说被喝茶，你说的代码指纹呢？

    这些答案，我估计我是看不到了，，，

    这一个月，我被编程随想的“狂热粉丝”疯狂攻击。

    明明只是技术讨论，偏偏要对我进行人身攻击，，，所以，为了眼不见心不烦。我就换个地方玩了！

    我现在正式宣布回归“看雪论坛”！

    感谢管理员没有把我发的贴子移到水区，没有折叠我的回复~
    谢谢！

    0 :   0 0