Dark Web中网络安全行业泄露状况

只要你和网站互相交换公钥，就可以用“签名”和“验签”来确认消息的真实性，因为私钥保密，黑客不能伪造签名，就能够保证通信双方的身份。

CA

到这里似乎已经大功告成，可惜还不是。

综合使用对称加密、非对称加密和摘要算法，我们已经实现了安全的四大特性，是不是已经完美了呢?

不是的，这里还有一个“公钥的信任”问题。因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说，怎么来判断这个公钥就是你或者张三丰的公钥呢?

这个“第三方”就是我们常说的CA(Certificate Authority，证书认证机构)。它就像网络世界里的公安局、教育部、公证中心，具有极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。

CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”(Certificate)。

OpenSSL

它是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它作为底层库来实现 TLS 功能，包括常用的 Web 服务器 Apache、Nginx 等。

 

比如诸葛亮使用上面提到的混合加密过程给关二爷发消息：“明天攻城” + “SHA-2 摘要”，关二爷收到后使用密钥将解密出来的会话密钥解密出明文消息，同时对明文消息使用解密出来的摘要算法进行摘要计算，接着比对两份“摘要”字符串是否一致，如果一致就说明消息完整可信，没有被敌军修改过。

消息被修改是很危险的，要以史为鉴，比如赵高与李斯伪造遗诏，直接把扶苏给送西天了，这太可怕了。

总结下就是通过摘要比对防止篡改，同时利用混合加密实现密文与摘要的安全传输。

数字签名和 CA

到这里已经很安全了，但是还是有漏洞，就是通信的两头。黑客可以伪装成网站来窃取信息。而反过来，他也可以伪装成你，向网站发送支付、转账等消息，网站没有办法确认你的身份，钱可能就这么被偷走了。

现在如何实现身份认证呢?

现实生活中，解决身份认证的手段是签名和印章，只要在纸上写下签名或者盖个章，就能够证明这份文件确实是由本人而不是其他人发出的。

非对称加密依然可以解决此问题，只不过跟之前反过来用，使用私钥再加上摘要算法，就能够实现“数字签名”，同时实现“身份认证”和“不可否认”。

就是把公钥私钥的用法反过来，之前是公钥加密、私钥解密，现在是私钥加密、公钥解密。但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。

重点就是使用非对称加密的“私钥”加密原文的摘要，对方则使用非对称加密的公钥解密出摘要，再比对解密出的原文通过摘要算法计算摘要与解密出的摘要比对是否一致。这样就能像签署文件一样证明消息确实是你发送的。

 

1. 生产者线程拿到锁后，其实就是进入了 Q2 阶段。首先检查队列是否容量已满，如果满了，那就要去 Q3 等待;
2. 如果不满，先检查一下队列原本是否为空，如果原来是空的，那就需要通知消费者;
3. 最后生产产品。

这里有个问题，为什么只能用 while 而不是 if?

其实在这一小段，生产者线程经历了几个过程：

1. 如果队列已满，它就没法生产，那也不能占着位置不做事，所以要把锁让出来，去 Q3 - 等待队列 等着;
2. 在等待队列里被唤醒之后，不能直接夺过锁来，而是要先加入 Q1 - 同步队列 等待资源;
3. 一旦抢到资源，关门上锁，才能来到 Q2 继续执行 wait() 之后的活，但是，此时这个队列有可能又满了，所以退出 wait() 之后，还需要再次检查 queue.size() == maxCapacity 这个条件，所以要用 while。

那么为什么可能又满了呢?

因为线程没有一直拿着锁，在被唤醒之后，到拿到锁之间的这段时间里，有可能其他的生产者线程先拿到了锁进行了生产，所以队列又经历了一个从不满到满的过程。

总结：在使用线程的等待通知机制时，一般都要在 while 循环中调用 wait() 方法。

消费者线程是完全对称的，我们来看代码。

（编辑：怀化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!