公钥加密

1、简介 Git是一个开源的分布式版本控制系统，能用于快速高效地处理任何或小或大的项目，它是Linus Torvalds为了帮助管理Linux内核开发而开发的一个源码开放的版本控制软件。 2、Linux平台安装git Git的工作需要调用curl、zlib、openssl等库的代码，因此在安装git之前需要安装这些依赖库，在Linux系统上使用apt-get或yum命令进行安装。 （1）命令行安装 首先安装库依赖： $ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ 　　libz-dev libssl-dev 然后继续安装git： $ sudo apt-get install git 安装完成后查看git的版本号： $ git --version 如下正常显示出版本号，则git安装完成： （2）源码安装 我们也可以通过Git的源码进行安装，先去Git官网下载最新版本源码，链接如下： https://git-scm.com/download 解压并安装下载的源码包： $ mv git-2.23.0.tar.gz ~/github/ $ cd ~/github/ $ tar -zxvf git-2.23.0.tar.gz $ cd git-2.23.0/ $ make prefix=/usr/local

~/.ssh/authorized_keys 文件内存入公钥.pub，退出后登陆即生效 PS： 1. 创建SSH密钥对 ssh-keygen -t rsa 指定算法 -f 指定密钥存储的文件。 2. 原理 本机收到随机字符，私钥加密，linux用公钥解密后确认是否OK。 来源： https://www.cnblogs.com/GW977/p/11433568.html

如果你的Apple ID账号（可使用邮箱来 注册 ）为Apple developer类型的话， 登录 之后是看不到Certificates, Indentifiers & Profiles信息的 Apple developer是最基础的账号类型，主要用来在App Store下载各种应用（包括xCode等开发工具和SDK库）及在iCloud上备份文件和照片 可通过点击下方的“Joining the Developer Program”链接，按照指引点击enroll按钮，付费99$/year之后，成为registered Apple developer 此时你才能看到Certificates, IDs & Profiles按钮，点击之后就可以进入Certificates, Indentifiers & Profiles面板了 Certificate（证书） Certificates（证书）是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件 用于用来给应用程序签名（Signature）的，只有经过签名的应用程序才能保证它的来源是可信任的，并且代码是完整的， 未经修改的 证书一般具有时效性，只在特定的时间段内有效。 苹果的证书分为Development和Distribution两种。Development证书用于开发和调试应用程序，可用于真机调试

一、概要 SSH 是 Secure Shell Protocol 的简写，由 IETF 网络工作小组（Network Working Group )制定；在进行数据传输之前，SSH先对联机数据包通过加密技术进行加密处理，加密后在进行数据传输。确保了传递的数据安全。SSH是专为远程登录会话和其他网络服务提供的安全性协议。利用 SSH 协议可以有效的防止远程管理过程中的信息泄露问题，在当前的生产环境运维工作中，绝大多数企业普遍采用SSH协议服务来代替传统的不安全的远程联机服务软件，如telnet(23端口，非加密的)等。 在默认状态下，SSH服务主要提供两个服务功能： 　　提供类似telnet远程联机服务器的服务，即上面提到的 SSH服务 。 　　类似FTP服务的sftp-server,借助SSH协议来传输数据的。提供更安全的 SFTP服务 (vsftp，proftp)。 二、认证过程 1.认证分类与说明 >>>主机验证： 通过主机验证,再通过该主机上的用户验证,就能唯一确定该用户的身份;一个主机上可以有很多用户,所以每台主机的验证只需一次,但主机上每个用户都需要单独进行用户验证; >>>身份验证： 一个主机上可以有很多用户,所以每台主机的验证只需一次,但主机上每个用户都需要单独进行用户验证 　 常用身份验证方法：ssh支持多种身份验证,最常用的是 密码验证机制和公钥认证机制

数字签名 用自己的私钥给数据加密就叫数字签名 公钥传输威胁 在A和B的通信中,C可以把自己的公钥发给A,让A把C的公钥当成B的公钥,这样的话.B拿到加密数据反而无法解密,而C却可以解密出数据.从而实现C截获AB之间的数据 所以在两者的通信中必须要对公钥的来源进行确认 A和B如果想安全交换公钥,就必须通过CA(证书颁发机构) 证书的通信过程 A和B首先都内置了CA的公钥 根CA的证书是自己给自己签名的(自签名) CA和证书 PKI: Public Key Infrastructure 签证机构：CA（Certificate Authority） 注册机构：RA 证书吊销列表：CRL 证书存取库： X.509：定义了证书的结构以及认证协议标准 版本号 序列号 签名算法 颁发者 有效期限 主体名称 主体公钥 CRL分发点 扩展信息 发行者签名 SSL SSL(Secure Socket Layer)和TLS(Transport Layer Security )本身是一个东西 实现功能: 机密性 认证 完整性 重放保护(正确同样的数据不能重复发送) 两阶段协议，分为握手阶段和应用阶段 握手阶段(协商阶段): 客户端和服务器端认证对方身份（依赖于PKI体系，利用数字证书进行 身份认证）,并协商通信中使用的安全参数、密码套件以及主密钥. 后续通信使用的所有密钥都是

参考： https://blog.51cto.com/11883699/2160032 上面说的已经很好地，我这里简单做个总结： 在网上我们做数据交互时候一般用的http协议，但是这种方式会使得交互内容明文化，很不安全，后来人们就想讲这个过程加密。 1）对于加密算法有对称加密和得对称加密算法，如果用对称加密算法加密客户端与服务端信息交互，方式：客户端给服务端发请求，服务端给客户端A回复使用对称秘钥A，客户端接收到对称秘钥A后回复知道了，之后客户端A就用对称秘钥A加密与服务端交互信息；同样服务端会给客户端B发送对称秘钥B，于此类推。但是这个过程中存在一个问题：对于这个秘钥协商的过程，是明文的，如果被第三方拦截，之后的操作在这个第三方面前都是明文的了 2） 为了解决1）中秘钥协商过程的明文容易被拦截获取，需要想个办法加密这一过程，于是乎我们可以用非对称秘钥加密算法（ 私钥加密后的密文，只要是公钥，都可以解密，但是反过来公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人 ）来处理这一过程，具体方案：客户端A给服务端发送请求，服务端给客户端A发送一个非对称加密算法的公钥，自己留一个私钥，客户端获得这个公钥后，用这个公钥给服务器发送信息（包含对称加密算法，对称秘钥等信息），服务端收到消息解密获得对象消息，并用收到的对称加密算法加密信息给客户端发送收到了

现在似乎比特币的热度已经过去，而在比特币、区块链流行的那段时间也是更多的作为一种投资手段被热议。 互联网已经普及，但是我们关于货币、金融、生产的认知还停留在资本论的时代，即使面对新兴的技术，也是在想，怎么才能大赚一笔。本文及本专栏并不是介绍如何暴富，而是想要借由这些新技术给大家展现一个新时代的缩影。 如果你也跟我一样看不懂很多介绍比特币的文章，那么这篇文章可能更适合你，因为我会和你一起站在一个小白的角度带着诸多疑问来了解这个技术 本文是基于中本聪的《比特币白皮书》来讲解的。先介绍一下中本聪，他是Bitcoin的创始人，2007年就致力于比特币的研究，而中本聪也可能并不是他的真名，也可能并不存在一个人是中本聪，而是一个团队。当然这些都不重要，更重要的是他的理论部分 互联网上的贸易，几乎都需要借助金融机构作为可资信赖的第三方来处理电子支付信息。虽然这类系统在绝大多数情况下都运作良好，但是这类系统仍然内生性地受制于“基于信用的模式”(trust based model)的弱点。 想想假如你在做生意，要给某个不熟悉的人A转一笔钱，那么你一定通过了第三方，可能是银行转账，可能是支付宝微信，也可能是双方签署了合同。 很少有人直接就把钱给对方了，因为你并不信任他。通过第三方，是因为我们信任银行，信任阿里巴巴和腾讯，信任合同的效力，归根结底可能是信任国家，信任现行的交易体系 但是信任是有很大成本的

前言 前不久移植了支付宝官方的SDK，以适用ASP.NET Core使用支付宝支付，但是最近有好几位用户反应在Linux下使用会出错，调试发现是RSA加密的错误，下面具体讲一讲。 RSA在.NET Core的改动 以前我们使用RSA加密主要是使用 RSACryptoServiceProvider 这个类，在.NET Core中也有这个类，但是这个类并不支持跨平台，所以如果你是用这个类来进行加/解密在windows上运行是完全没有错误的，但是只要你一放到Linux下就会出现异常。 查阅资料得知，要解决这个问题，需要改用 System.Security.Cryptography.RSA.Create() 工厂方法，使用它之后，在 Windows 上创建的是 System.Security.Cryptography.RSACng 的实例，在 Mac 与 Linux 上创建的是 System.Security.Cryptography.RSAOpenSsl 的实例，它们都继承自 System.Security.Cryptography.RSA 抽象类。 RSACng： 相关资料： https://docs.microsoft.com/zh-cn/dotnet/api/system.security.cryptography.rsacng?view=netcore-2.0

什么是HTTP协议？ HTTP协议全称Hyper Text Transfer Protocol，翻译过来就是超文本传输协议，位于TCP/IP四层模型当中的应用层。 HTTP协议通过请求/响应的方式，在客户端和服务端之间进行通信。 这一切看起来很美好，但是HTTP协议有一个致命的缺点： 不够安全 。 HTTP协议的信息 传输 完全以明文方式，不做任何加密，相当于是在网络上“裸奔”。这样会导致什么问题呢？让我们打一个比方： 小灰是客户端，小灰的同事小红是服务端，有一天小灰试图给小红发送请求。 但是，由于传输信息是明文，这个信息有可能被某个中间人恶意截获甚至篡改。这种行为叫做 中间人攻击 。 如何进行加密呢？ 小灰和小红可以事先约定一种 对称加密 方式，并且约定一个随机生成的密钥。后续的通信中，信息发送方都使用密钥对信息加密，而信息接收方通过同样的密钥对信息解密。 这样做是不是就绝对安全了呢？并不是。 虽然我们在后续的通信中对明文进行了加密，但是第一次约定加密方式和密钥的通信仍然是明文，如果第一次通信就已经被拦截了，那么密钥就会泄露给中间人，中间人仍然可以解密后续所有的通信内容。 这可怎么办呢？别担心，我们可以使用 非对称加密 ，为密钥的传输做一层额外的保护。 非对称加密的一组秘钥对中，包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密；也可以用私钥加密，用公钥解密。

一、前言： 先来观察这两张图，第一张访问域名http://www.12306.cn，谷歌浏览器提示不安全链接，第二张是https://kyfw.12306.cn/otn/regist/init，浏览器显示安全，为什么会这样子呢？2017年1月发布的Chrome 56浏览器开始把收集密码或信用卡数据的HTTP页面标记为“不安全”，若用户使用2017年10月推出的Chrome 62，带有输入数据的HTTP页面和所有以无痕模式浏览的HTTP页面都会被标记为“不安全”，此外，苹果公司强制所有iOS App在2017年1月1日前使用HTTPS加密。 二、HTTP和HTTPS发展历史 什么是HTTP? 超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。 发展历史： 版本 产生时间 内容 发展现状 HTTP/0.9 1991年 不涉及数据包传输，规定客户端和服务器之间通信格式，只能GET请求 没有作为正式的标准 HTTP/1.0 1996年 传输内容格式不限制，增加PUT、PATCH、HEAD、 OPTIONS、DELETE命令 正式作为标准 HTTP/1.1 1997年 持久连接(长连接)、节约带宽、HOST域