数字签名

下文主要从加密算法的特征、常用加密算法和加密工具等方面，梳理和比较对称加密、单向加密和公钥加密的概念及其之间的联系。 对称加密 采用单钥密码的加密方法，同一个密钥可以同时用来加密和解密，这种加密方法称为对称加密，也称为单密钥加密。常用的单向加密算法： DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合； 3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高； AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高，支持128、192、256、512位密钥的加密； Blowfish 算法特征： 1、加密方和解密方使用同一个密钥； 2、加密解密的速度比较快，适合数据比较长时的使用； 3、密钥传输的过程不安全，且容易被破解，密钥管理也比较麻烦； 加密工具： openssl，它使用了libcrypto加密库、libssl库即TLS/SSL协议的实现库等。TLS/SSL是基于会话的、实现了身份认证、数据机密性和会话完整性的TLS/SSL库。openssl官网。 gpg 单向散列加密 单向加密又称为不可逆加密算法，其密钥是由加密散列函数生成的。单向散列函数一般用于产生消息摘要，密钥加密等，常见的有： 1、MD5

鲍勃有两把钥匙，一把是公钥，另一把是私钥。 鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。 苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。 鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。 鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。 然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。 鲍勃将这个签名，附在信件下面，一起发给苏珊。 苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。 苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。 复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。 后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥

一、公钥加密 假设一下，我找了两个数字，一个是1，一个是2。我喜欢2这个数字，就保留起来，不告诉你们(私钥），然后我告诉大家，1是我的公钥。 我有一个文件，不能让别人看，我就用1加密了。别人找到了这个文件，但是他不知道2就是解密的私钥啊，所以他解不开，只有我可以用 数字2，就是我的私钥，来解密。这样我就可以保护数据了。 我的好朋友x用我的公钥1加密了字符a，加密后成了b，放在网上。别人偷到了这个文件，但是别人解不开，因为别人不知道2就是我的私钥， 只有我才能解密，解密后就得到a。这样，我们就可以传送加密的数据了。 二、私钥签名 如果我用私钥加密一段数据（当然只有我可以用私钥加密，因为只有我知道2是我的私钥），结果所有的人都看到我的内容了，因为他们都知 道我的公钥是1，那么这种加密有什么用处呢？ 但是我的好朋友x说有人冒充我给他发信。怎么办呢？我把我要发的信，内容是c，用我的私钥2，加密，加密后的内容是d，发给x，再告诉他 解密看是不是c。他用我的公钥1解密，发现果然是c。 这个时候，他会想到，能够用我的公钥解密的数据，必然是用我的私钥加的密。只有我知道我得私钥，因此他就可以确认确实是我发的东西。 这样我们就能确认发送方身份了。这个过程叫做数字签名。当然具体的过程要稍微复杂一些。用私钥来加密数据，用途就是数字签名。 总结：公钥和私钥是成对的，它们互相解密。 公钥加密，私钥解密。

HTTPS 详解一：附带最精美详尽的 HTTPS 原理图 HTTPS详解二：SSL / TLS 工作原理和详细握手过程 在上篇文章 HTTPS详解一 中，我已经为大家介绍了 HTTPS 的详细原理和通信流程，但总感觉少了点什么，应该是少了对安全层的针对性介绍，那么这篇文章就算是对 HTTPS 详解一 的补充吧。还记得这张图吧。 HTTPS 和 HTTP的区别 显然，HTTPS 相比 HTTP最大的不同就是多了一层 SSL (Secure Sockets Layer 安全套接层)或 TLS (Transport Layer Security 安全传输层协议)。有了这个安全层，就确保了互联网上通信双方的通信安全，那么这个安全层是怎么工作的，SSL / TLS 握手过程又是怎样的呢？本文将对这些问题一一解答。 1、SSL / TLS 以及 SSL / TLS 握手的概念 SSL 和 TLS 协议可以为通信双方提供识别和认证通道，从而保证通信的机密性和数据完整性。TLS 协议是从Netscape SSL 3.0协议演变而来的，不过这两种协议并不兼容，SSL 已经被 TLS 取代，所以下文就以 SSL 指代安全层。 TLS 握手是启动 HTTPS 通信的过程，类似于 TCP 建立连接时的三次握手。 在 TLS 握手的过程中，通信双方交换消息以相互验证，相互确认

http基本概念 http是一个无状态 ，无连接的基于TCP协议的单向应用层协议 一、无连接 无连接即每次链接只处理一个请求，请求和应答后就断开链接 二、无状态 http的每次请求都是独立的，不相关的，协议对事物处理没有记忆功能。 HTTP无状态的特性严重阻碍了这些交互式应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持HTTP状态的技术就应运而生了，一个是Cookie，而另一个则是Session。 HTTP请求报文 HTTP请求报文由3部分组成（报文行+报文头+报文体）： 常见的HTTP响应报文头属性 Cache-Control 响应输出到客户端后，服务端通过该报文头属告诉客户端如何控制响应内容的缓存。 常见的取值有private、public、no-cache、max-age，no-store，默认为private。 private: 客户端可以缓存 public: 客户端和代理服务器都可缓存（前端的同学，可以认为public和private是一样的） max-age=xxx: 缓存的内容将在 xxx 秒后失效 no-cache: 需要使用对比缓存来验证缓存数据 no-store: 所有内容都不会缓存 默认为private，缓存时间为31536000秒（365天）也就是说，在365天内再次请求这条数据

一、什么是Hash签名？ Hash签名是最主要的数字签名方法，也称之为数字摘要法（Digital Digest）或数字指纹法（Digital Finger Print）。数字摘要就是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。 二、数字签名和验证的文件传输过程如下： （1） 被发送文件用MD5编码加密产生128bit的数字摘要。 （2） 发送方用自己的私用 密钥 对摘要再加密，这就形成了数字签名。 （3） 将原文和加密的摘要同时传给对方。 （4） 对方用发送方的公共密钥对摘要解密，同时对收到的文件用MD5编码加密产生又一摘要。 （5） 将解密后的摘要和收到的文件在接收方重新加密产生的摘要相互对比。如两者一致，则说明传送过程中信息没有被破坏或篡改过。否则不然。 三、常见Hash算法 ： MD2 MD4 MD5 HAVAL SHA 来源： https://www.cnblogs.com/naray/p/4191543.html

package main import ( "crypto/ecdsa" "crypto/elliptic" "crypto/rand" "crypto/sha256" "encoding/hex" "fmt" "log" "math/big" ) func main() { // 1、对需要签名的文件进行hash运算 data := "from xiaoxiao to maomao 100 btc" hashInstance := sha256.New() hashInstance.Write([]byte(data)) hashed := hashInstance.Sum(nil) // 2、生成私钥和公钥字节 privateKey, publicKeyBytes := NewKeyPair() // 3、生成签名的der编码格式 derSignString := ECDSASign(hashed, privateKey) fmt.Printf("签名信息为：%s\n", derSignString) // 4、验证签名 flag := ECDSAVerify(publicKeyBytes, hashed, derSignString) fmt.Println("签名验证结果：", flag) } // NewKeyPair 生成私钥和公钥，生成的私钥为结构体ecdsa

http://www.cnblogs.com/kingsleylam/p/4985571.html 数字签名原理简介（附数字证书） 首先要了解什么叫对称加密和非对称加密，消息摘要这些知识。 1. 非对称加密 在通信双方，如果使用非对称加密，一般遵从这样的原则：公钥加密，私钥解密。同时，一般一个密钥加密，另一个密钥就可以解密。 因为公钥是公开的，如果用来解密，那么就很容易被不必要的人解密消息。因此， 私钥也可以认为是个人身份的证明。 如果通信双方需要互发消息，那么应该建立两套非对称加密的机制（即两对公私钥密钥对），发消息的一方使用对方的公钥进行加密，接收消息的一方使用自己的私钥解密。 2.消息摘要 消息摘要可以将消息哈希转换成一个固定长度的值唯一的字符串。值唯一的意思是不同的消息转换的摘要是不同的，并且能够确保唯一。 该过程不可逆 ，即不能通过摘要反推明文（似乎SHA1已经可以被破解了，SHA2还没有。一般认为不可破解，或者破解需要耗费太多时间，性价比低）。 利用这一特性， 可以验证消息的完整性。 消息摘要通常用在数字签名中，下面介绍用法。 了解基础知识之后，就可以看一下数字签名和数字证书了。 3.数字签名 假设现在有通信双方A和B，两者之间使用两套非对称加密机制。 现在A向B发消息。 那么，如果在发送过程中，有人修改了里面密文消息，B拿到的密文，解密之后得到明文，并非A所发送的

现象： 我更新ubuntun18.04的软件源为国内，再执行apt-get update报错了。 root@c:/home/c# apt-get update 获取:1 http://mirrors.aliyun.com/ubuntu bionic InRelease [242 kB] 获取:2 http://mirrors.aliyun.com/ubuntu bionic-security InRelease [88.7 kB] 获取:3 http://mirrors.aliyun.com/ubuntu bionic-updates InRelease [88.7 kB] 错误:1 http://mirrors.aliyun.com/ubuntu bionic InRelease 由于没有公钥，无法验证下列签名： NO_PUBKEY 3B4FE6ACC0B21F32 错误:2 http://mirrors.aliyun.com/ubuntu bionic-security InRelease 由于没有公钥，无法验证下列签名： NO_PUBKEY 3B4FE6ACC0B21F32 获取:4 http://mirrors.aliyun.com/ubuntu bionic-proposed InRelease [242 kB] 获取:5 http://mirrors.aliyun

介绍 http [1] 是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是一种应用层协议，可用于将超文本服务器中文本、图片、音视频等内容传输到客户端浏览器。 构建与互联网之上的万维网，其主要组成部分就是http协议。目前使用的最广泛的http协议版本是http1.1。 最初的HTTP协议是万维网1991年诞生时，蒂姆·伯纳斯·李爵士（Sir Tim Berners-Lee）在European Organization for Nuclear Research使用的协议。之后万维网协会（World Wide Web Consortium）和Internet工作小组（Internet Engineering Task Force）合作，并最终发布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定义了我们今天普遍使用的HTTP协议的一个版本——HTTP1.1。 在TCP/IP参考模型中和OSI参考模型中，http协议处于应用层的位置，http规定了客户端和Web服务端的通信协议，而html则规定了传输的内容的格式、类型。https是在http的基础上，增加了TLS/SSL协议，为通信内容进行加密操作。 http通信过程 http协议默认使用TCP的80端口进行通信。通过在浏览器中输入网站地址，URL (Uniform