公钥加密

对称加密算法 同一个秘钥可以用于加密和解密，缺点是秘钥的保存安全问题 不对称加密算法 工作过程： 1、乙方生成一对密钥（公钥和私钥）并将公钥向其它方公开。 2、得到该公钥的甲方使用该密钥对机密信息进行加密后再发送给乙方。 3、乙方再用自己保存的另一把专用密钥（私钥）对加密后的信息进行解密。乙方只能用其专用密钥（私钥）解密由对应的公钥加密后的信息。 在传输过程中，即使攻击者截获了传输的密文，并得到了乙的公钥，也无法破解密文，因为只有乙的私钥才能解密密文。 同样，如果乙要回复加密信息给甲，那么需要甲先公布甲的公钥给乙用于加密，甲自己保存甲的私钥用于解密。 转载于:https://www.cnblogs.com/JAYIT/p/5614329.html 来源： https://blog.csdn.net/weixin_30737433/article/details/99814832

引言 HTTP应用层的抓包已经成为日常工作测试与调试中的重要一环，最近接触新项目突然之间发现之前的抓包手段都不好使了，顿时模块与模块之间的前端与服务之间的交互都变成了不可见，整个人都好像被蒙住了眼睛。 其实自己也很早就发现平时使用的支付宝等APP使用Fiddler 或 Charles这类代理抓包软件默认情况下就无法抓取请求的，但使用Wireshark这类网卡抓包软件可以看到这些APP的流量，而已这些流量也表明这些APP使用的主要应用层协议仍然是HTTP（https），不过我们的代理抓包工具却失效了。如今终于在实际工作中遇到了，也不得不解决了，毕竟眼前有东西挡住会让我浑身不适。 代理抓包原理 为了弄明白为什么Fiddler 或 Charles对这些APP无效，我们有必要先了解代理抓包我原理（当然您不想了解也是完全可以的，直接看后面的 实际操作 就可以完成，原理分析什么的可以有兴趣随时回来看） Fiddler 或 Charles 这类使用的代理的抓包软件与Wireshark是完全不同的（Wireshark 使用的网卡数据复制，只要是经过指定网卡都会被抓取），其只能对使用代理的应用层网络协议生效，比如常见的HTTP（https），Websocket 。 这里以HTTP为例简单说明下 客户端需要完成一次HTTP请求，通常需要先找到服务器，客户端会根据http请求中url的主机名

1. HTTPS定义 　　Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本传输协议，网景公式设计了SSL(Secure Sockets Layer)协议用于对Http协议传输的数据进行加密，保证会话过程中的安全性。 　　缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure 　　两大作用：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。 2. 密码学基础　 明文： 明文指的是未被加密过的原始数据。 密文：明文被某种加密算法加密之后，会变成密文，从而确保原始数据的安全。密文也可以被解密，得到原始的明文。 密钥：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。 对称加密对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。 其加密过程如下：明文 + 加密算法 + 私钥 => 密文 解密过程如下：密文 + 解密算法 + 私钥 => 明文 对称加密中用到的密钥叫做私钥，私钥表示个人私有的密钥，即该密钥不能被泄露。 其加密过程中的私钥与解密过程中用到的私钥是同一个密钥，这也是称加密之所以称之为“对称”的原因

1.RSA加密解密： 　(1)获取密钥，这里是产生密钥，实际应用中可以从各种存储介质上读取密钥 (2)加密 (3)解密 2.RSA签名和验证 　(1)获取密钥，这里是产生密钥，实际应用中可以从各种存储介质上读取密钥 (2)获取待签名的Hash码 (3)获取签名的字符串 (4)验证 3.公钥与私钥的理解： 　(1)私钥用来进行解密和签名，是给自己用的。 　(2)公钥由本人公开，用于加密和验证签名，是给别人用的。 (3)当该用户发送文件时，用私钥签名，别人用他给的公钥验证签名，可以保证该信息是由他发送的。当该用户接受文件时，别人用他的公钥加密，他用私钥解密，可以保证该信息只能由他接收到。 class RSACryption { #region RSA 加密解密 #region RSA 的密钥产生 /// <summary> /// RSA产生密钥 /// </summary> /// <param name="xmlKeys">私钥</param> /// <param name="xmlPublicKey">公钥</param> public void RSAKey(out string xmlKeys, out string xmlPublicKey) { try { System.Security.Cryptography.RSACryptoServiceProvider rsa

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

本文主要讲解Http与https的区别，以及https是怎样加密来保证安全的。 首先讲这俩个协议的简单区别： HTTP：超文本传输协议。 HTTPS：安全套接字层超文本传输协议HTTP+SSL HTTP：客户端和服务器端传递的是明文的消息。 HTTPS：将明文进行加密后再在客户端和服务器之前进行传递。 HTTP采用80端口，而HTTPS采用443端口。 HTTPS需要申请证书。 HTTPS采用非对称加密和对称加密两种加密方式来保证传输信息的安全性： 非对称加密：用公钥和私钥来加解密（有同学这里不懂的话可以看看资料）。 对称加密：加密解密都用同一套秘钥。 注：非对称加密更加安全，对称加密速度更快。 https的请求流程： 客户端（浏览器）向服务器请求https连接。 服务器返回证书（公钥）到客户端。 客户端随机的秘钥A（用于对称加密）。 客户端用公钥对A进行加密。 客户端将加密A后的密文发送给服务器。 服务器通过私钥对密文进行解密得到对称加密的秘钥。 客户端与服务器通过对称秘钥加密的密文通信。 上述过程中第2步骤中是存在风险的，因为公钥是暴露出来的，当公钥被中间人非法截获时，同时将公钥替换成中间人自己的公钥发送给客户端，从而得到对称加密的秘钥，进而伪装与客户端通信。 为了解决这种问题，就引入了数字证书与数字签名 所以在第2步骤时，服务器发送了一个SSL证书给客户端

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

众所周知，WEB服务存在http和https两种通信方式，http默认采用80作为通讯端口，对于传输采用 不加密 的方式，https默认采用443，对于传输的数据进行 加密传输 目前主流的网站基本上开始默认采用HTTPS作为通信方式，一切的考虑都基于对安全的要求，那么如何对自己的网站配置HTTPS通信，是本文着重介绍的 本文的主要内容包括：https加密传输的原理、如何申请https所用的CA证书，如何配置WEB服务支持https 1、https原理通俗讲解 https=http+ssl，顾名思义，https是在http的基础上加上了SSL保护壳，信息的加密过程就是在SSL中完成的 首先我们先不谈https，先从一个简单的通讯原理图讲起： http通信原理 客户端发送一句client hello给服务器端，服务器端返回一句serverhello给客户端，鉴于本文讨论是https的加密主题，我们只讨论信息传输的加密问题 实现客户端和服务端发送的信息client hello 和server hello，即使中间的包被窃取了，也无法解密传输的内容 http：client hello和server hello在通讯的过程中，以明文的形式进行传输，采用wireshark抓包的效果如下图： 有没有感觉这个的信息传输是完全暴露在互联网上面，你请求的所有信息都可以被窥测到，是不是感觉心一凉

TrueLicense是一个开源的证书管理引擎，可以用于license的生成和有效性的验证。 一 使用keytool生产密钥对 keytool是jdk里面自带的命令。我们直接用keytool命令来生成密钥对。需要执行的命令如下(命令里面的参数大家根据情况不同做相应的调整) ## 1. 生成私匙库 # validity：私钥的有效期多少天 # alias：私钥别称 # keystore: 指定私钥库文件的名称(生成在当前目录) # storepass：指定私钥库的密码(获取keystore信息所需的密码) # keypass：指定别名条目的密码(私钥的密码) keytool -genkeypair -keysize 1024 -validity 3650 -alias "privateKey" -keystore "privateKeys.keystore" -storepass "a123456" -keypass "a123456" -dname "CN=localhost, OU=localhost, O=localhost, L=SH, ST=SH, C=CN" ## 2. 把私匙库内的公匙导出到一个文件当中 # alias：私钥别称 # keystore：指定私钥库的名称(在当前目录查找) # storepass: 指定私钥库的密码 # file：证书名称 keytool

RSA数字签名与加密、解密间的关系 提及RSA，大家会想到公钥、私钥、加密、解密、数字签名、数字信封。。。 但也许大家和曾经的我一样，对其中的某些理解会存在误区，最近看了下关于RSA的RFC 2313文档，再加上自己的一些测试，终于理清了其中的一些关系，主要包括以下几点： 1、公钥和私钥间的关系； 2、数字签名和私钥加密间的关系； 3、数字签名的验证具体是怎样的过程； 公钥与私钥 一般，我们可以用RSA算法生成一对密钥，公钥发放给外部客户，私钥自己保管；有以下一些应用场景： 【公钥加密、私钥解密】或者【私钥加密、公钥验证】 对于第一种场景，似乎没有什么疑问；但是对于第二种场景，公钥验证时到底是如何验证法个人有个人的说法，我以前一直以为是和数字证书一样（当然这个理解有误，关于数字证书后续也会详述），只能验证不能被解密！但经过我的测试证明： 私钥加密是可以用公钥解密的 ；所以说对于RSA算法，用任何一方密钥加密都可以用另外一个密钥解密；这也从另外一个角度说明，其实 公钥和私钥是相对而言的 ，发放其中一个密钥出去，另外一个自然也就成为私钥了；对于该观点，很多同学都已经提到过，但我以前一直认为这是一个误解，汗自己一把； 另外，当我们使用证书的时候，比如pfx、cer、jks、rsa等，从中我们可以看出私钥比公钥暴露出了更多的信息，大家可以自行导出xml查看，当然其中很多参数是用来加速的