公钥加密

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

[TOC] 1.1、了解微服务状态 微服务集群中的每个服务，对外提供的都是Rest风格的接口，而Rest风格的一个最重要的规范就是：服务的无状态性。 什么是无状态？ 1.服务端不保存任何客户端请求者信息 2.客户端的每次请求必须自备描述信息，通过这些信息识别客户端身份 无状态，在微服务开放中，优势是？ 1.客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同一台服务 2.服务端的是否集群对客户端透明 3.服务端可以任意的迁移和伸缩 4.减小服务端储存压力 1.2、无状态登录实现原理 服务器端生产唯一标识(注意：最终需要进行校验) 方案1：UUID，数据单一，不能包含种类过多的信息。 方案2：RAS加密，数据多样，需要使用算法，有一定的理解难度。【使用】 浏览器储存和自动携带数据 方案1：使用cookie，有很多局限性(大小，个数) 方案2：请求参数，get请求URL有长度限制，每一个路径都需要处理比较麻烦。 方案3：浏览器localStroage存储，请求头携带。【使用】 2.1、RAS工具 服务与服务之间共享数据，采用JWT先生成数据，在另一个服务中解析数据，为了保证数据安全性，使用RAS对数据进行加密。 使用RAS加密保证token数据在传输过程中不会被篡改 RAS：非对称加密算法 特点 同时生产一对密钥：公钥和私钥 公钥秘钥：用于加密 私钥秘钥：用于解密

在登录远程linux主机时，为了避免输入密码，可以将本地ssh公钥上传到远程linux主机上，进行一些配置，达到免密登录的效果。 本地生成ssh密钥对 # ssh-keygen -t rsa -C "<email>" ssh-keygen -t rsa -C "xxx@163.com" # rsa: RSA加密 windows下，先安装git，然后再git终端中输入上述命令，生成的密钥在 /c/User/<username>/.ssh/ 文件夹中。 id_rsa 为私钥文件， id_rsa.pub 为公钥文件。 远程linux主机配置 在远程linux主机的 ~/.ssh/ 目录下新建 authorized_keys 文件。将本地公钥复制到 authorized_keys 中。 检查ssh配置 sudo vim /etc/ssh/sshd_config 检查下面三项是否配置。 PasswordAuthentication yes 　　　　　　 # 口令登录 RSAAuthentication yes 　　　　　　　　　 # RSA认证 PubkeyAuthentication yes 　　　　　　　 # 公钥登录 # 当修改了ssh配置时，重启ssh服务 sudo service ssh rstart 然后验证是否可以免密登录。 来源： CSDN 作者： 码上看世界 链接：

理解 BLS 签名算法 来源 https://medium.com/cryptoadvance/bls-signatures-better-than-schnorr-5a7fe30ea716 原文标题：《干货：理解 BLS 签名算法》 作者：Stepan 翻译 & 校对：wuwei & 阿剑 之前的文章中，我介绍了 Schnorr 签名算法和它的优势。现在，我来介绍下 BLS （Boneh-Lynn-Shacham）签名算法以及它相比 Schnorr 的优胜之处。 长话短说，我们已经知道： ECDSA 签名算法已经足够胜任它的工作，但也仅限于此。它无法做签名聚合或者密钥聚合，因此只能挨个对签名进行验证。在验证多重签名的交易时，此举过于繁琐，我们需要逐个验证所有的签名及其对应的公钥，耗费大量的区块空间和交易费。 Schnorr 签名算法就好多了，它可以把一笔交易中的所有签名和公钥合并成单个签名和公钥，且合并过程不可见（无从追溯这个签名或公钥是否通过合并而来）。另外，可以一次性对合并后的签名做验证，加快了区块验证的速度。当然，该算法也有一些不足 : 多重签名需要多次（签名者之间的）通信，这对冷钱包来说过于麻烦； 聚合签名算法依赖随机数生成器，而不像 ECDSA 那样可以使用指定的随机点（R）； m-n 多重签名机制比较取巧，需要构建公钥的默克尔树。当 m 和 n 较大时

1. 自动获取IP地址的命令是什么？您知道在什么情况下，您的Linux才可以自动获取IP地址？ 使用命令 dhclient可以自动获取IP地址，只有当我们的Linux所在的网络有dhcp服务器才可以自动获取ip，dhcp服务就是一个分发ip的管理器。 2. 远程连接Linux服务器，需要Linux服务器开启sshd服务，那么sshd服务默认监听哪个端口？这个端口是否可以自定义呢？如果可以，如何自定义？ sshd服务默认监听22端口，这个端口是可以自定义的，需要修改/etc/ssh/sshd_config配置文件，把 "#Port 22"修改为"Port 12553" 其中12553就是新定义的sshd端口。 3. 列举出常用的远程连接linux的终端工具有哪些？ putty, Secure CRT, Secure SSh, Xshell 等 4. 手动配置IP，需要修改哪个配置文件？ 更改默认的配置文件，需要更改哪些地方，需要增加哪几行？ 需要修改配置文件 /etc/sysconfig/network-scripts/ifcfg-eth0 需要修改的有： 更改：BOOTPROTO=static 增加：IPADDR=192.168.0.11 增加：NETMASK=255.255.255.0 增加：GATEWAY=192.168.0.1 增加：DNS1=192.168.0.1 5.

git clone git@github.com:*** //提示 正克隆到 'pose-hg-train'... Warning: Permanently added the RSA host key for IP address '一个IP地址' to the list of known hosts. Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 当从终端克隆一个git项目时 1 .首先你要有一个github账号 2 .明白公钥问题 　　可自行百度，以下是我理解的 　　公钥就像是我的银行卡卡号，我把我的卡号（公钥）给别人，别人才能往我的卡号里存钱（信息用公钥加密后发送给我），但是只有我自己有银行卡密码（私钥），只有我自己能够取钱（破解信息）。 3 .找到自己电脑的公钥 先去查看是否生成过公钥 cd ~/.ssh/ 文件夹下如果有文档id_rsa.pub，且里面有公钥 则不用重新生成公钥，否则执行 ssh-keygen 　　　　　 生成公钥打开本地~/.ssh/id_rsa.pub 复制公钥 4 .把公钥给github

一、区块链的安全性 由于全球区块链技术尚处于开发阶段，还未成熟，还没有完全解决客户端安全、应用安全等安全性问题。区块链技术是多种已有技术集成的创新结果，它包含了私钥加密算法、P2P网络以及工作量证明机制POW。这些技术也并不是坚不可破的，也存在着一些弊端，例如从加密算法来看，随着最新算法以及计算能力的提高，其目前安全的加密信息很有可能被解密。 二、区块链私钥 区块链私钥，就是一个随机选出的数字。控制了私钥就等于控制了一个比特币地址中的所有资金。私钥必须始终保持机密，最好冷备份，就是手写在纸上，然后妥善保管，谨防丢失，私钥一旦丢失就难以复原，其所保护的比特币也将永远丢失。私钥不能存放与邮箱、记事本等与网络连接的电子文件中，以防黑客入侵，造成资金损失。因为一旦被泄露给第三方，相当于该私钥保护之下的比特币也拱手相让了。 三、区块链公钥 很多人听到公钥就觉得是一把大家都能使用的钥匙，事实并非如此，公钥不是钥匙，而是1976年由美国斯坦福大学的迪菲和赫尔曼提出的一种密码体制。 这种密码体制在加密学中又叫做非对称加密体制，是对称加密（使用用户名与密码）方式的提高。公钥最早被用于数据的加密和解密，现在广泛用于虚拟货币的存储和交易。 公钥是由私钥生成的，但是无法通过公钥倒推得到私钥，公钥的作用是跟签名配合用来证明“我就是私钥的主人”。公钥和私钥一起组成一个密钥对，保存在钱包中

参考链接： 　　 http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html 　　 https://blog.csdn.net/weixin_37887248/article/details/82805508 这里涉及到了非对称加密的原理，一般加密和解密过程使用的是不同的密钥：公钥和私钥 　　对要传输的内容，使用公钥加密的话，只能用私钥解密 　　对要传输的内容，使用私钥加密的话，则只能用公钥解密。 而常说的数字签名，就与以上的第2个步骤有关，当然实际上还有其他步骤 比较典型的有RSA加密，算法安全性依赖于：大素数难以分解。因此其算法复杂度比较大，加解密效率相对来说不高。 通过下面的例子来说明数字签名和证书中心的作用 通信双方：A、B； A的公钥和私钥：PuA、PrA； B的公钥和私钥：PuB、PrB RSA通信过程，简单使用一次加密和解密，然后问题多多的方式如下 　　1. A准备发送内容，对内容使用公钥PuB进行加密，然后将密文传输给B 　　2. B收到A发送的数据，使用私钥PrB，解密并得到明文；读取之后，B现在要给A回复，因此使用公钥PuA对内容进行加密，将密文传输给A 　　3. A收到B的回复，使用公钥PuB对内容进行解密，得到明文。至此，一次完整的通信过程完成。 　

目录 1. 引言 2. 了解https、证书、openssl及keytool 2.1 https 2.1.1 什么是https 2.1.2 https解决什么问题 2.2 证书 2.2.1 证书内容 2.2.2 验证证书过程 2.2.3 证书种类 2.3 openssl 2.4 keytool 3. 自签证书 3.1 证书生成过程 3.1.1 自建CA证书 3.1.2 CA签发服务端证书 3.1.3 证书存入keystore文件 3.2 证书生成注意事项 4. 后端springboot工程添加https访问 4.1 springboot工程添加ssl配置项 4.2 添加内置tomcat的http转发https 5. 前端apache添加https访问 5.1 apached.conf添加ssl支持 5.1.1 启用需要的模块 5.1.2 引入ssl配置 5.1.3 修改配置Directory 5.2 httpd-ssl.conf 添加ssl配置 5.3 添加http转发https 5.4 访问后端接口地址添加https地址 6. 客户端添加证书 7. 总结 参考资料 往期文章 一句话概括：现在网站访问基本都需要使用https访问，否则浏览器就会报不安全提示，本文针对springboot+apache前后端分离的项目的https设置与部署进行说明。 1. 引言 当前访问互联网上的应用

1、CA（为服务器做担保的第三方机构）将包含CA【公钥C】等信息的【证书C】发送给浏览器； 2、服务器将其【公钥S】和网站信息发送给CA； 3、CA用CA【私钥C】将这些信息加密得到了签名后的【服务器证书S】，发送给服务器； 4、浏览器输入使用https协议的url; 5、浏览器与服务器建立TCP连接； 6、浏览器与服务器建立TLS(SSL)连接（1）：主要传输浏览器支持的加密算法列表等，其中还包括用于生成对称密钥的客户端随机数； 7、浏览器与服务器建立TLS(SSL)连接（2）：传输服务器选择的加密算法，其中包括用于生成对称密钥的服务器随机数； 8、浏览器与服务器建立TLS(SSL)连接（3）：传输【服务器证书S】（经过CA私钥加密的公钥、域名等）； 9、浏览器用CA【证书C】的公钥解密【服务器证书S】，进行证书校验，验证解密后的【服务器证书S】中的域名是否正确并获得服务器【公钥S】； 10、浏览器与服务器建立TLS(SSL)连接（4）：浏览器产生pre_master key，用服务器发来的【公钥S】加密后发给服务器（用生成对称密钥）； 11、浏览器用客户端随机数、服务器随机数、pre_master key生成对称加密【密钥A】； 12、服务器用其【密钥S】将收到的pre_master key解密，生成对称加密【密钥A】； 13、浏览器与服务器建立TLS(SSL)连接（5）