全部博文（695）
分类： 网络与安全
2016-03-22 16:30:00
转自： http://my.oschina.net/shede333/blog/359290
作者：shede333
&& http://blog.sina.com.cn/u/1509658847
版权声明：原创文章，版权声明：自由转载-非商用-非衍生-保持署名 | [Creative Commons BY-NC-ND 3.0][]
Digital Encryption Standard. Obsolete standard.
单密钥算法,是信息的发送方采用密钥A进行数据加密,信息的接收方采用同一个密钥A进行数据解密.
单密钥算法是一个对称算法.
算法好在加/解速度快,密钥量短,采用对称加密
Digital Signature Algorithm. based on discrete logarithms computation.
主要用于签名
在DSA数字签名和认证中，发送者使用自己的私钥对文件或消息进行签名，接受者收到消息后使用发送者的公钥
DSA只是一种算法，和RSA不同之处在于它不能用作加密和解密，也不能进行密钥交换，
只用于签名,它比RSA要快很多.
DSA只能与SHA-1一起使用，而RSA可以与任何摘要算法一起使用。DSA签名不包括摘要标识符，所以如果允许多种摘要算法就会使DSA遭受前面RSA里面介绍的那种替换攻击。DSA主要依赖于整数有限域离散对数难题。
与RSA不同的是，RSA是对签名数据“解密”后再比对摘要值，而DSA中摘要值是需要参与计算的。
RSA 是一种非对称加解密算法。
RSA 与 DSA 都是非对称加密算法。其中RSA的安全性是基于极其困难的大整数的分解（两个素数的乘积）；DSA 的安全性
是基于整数有限域离散对数难题。基本上可以认为相同密钥长度的 RSA 算法与 DSA 算法安全性相当。
公钥用于加密，它是向所有人公开的；私钥用于解密，只有密文的接收者持有。
DSA 用于签名，而 RSA 可用于签名和加密。
*refer: *
公钥 :用于向外发布，任何人都能获取，
私钥 :要自己保存，切勿给别人
一下两种情况经常有人弄混，一定要理解。
情况1：公钥用于【加密】， 私钥用于【解密】
如果加密密钥是公开的，这用于客户给私钥所有者上传加密的数据，这被称作为公开密钥加密(狭义)。
例如，网络银行的客户发给银行网站的账户操作的加密数据。HTTPS 等。
情况2：公钥用于【解密】，私钥用于【加密】
如果解密密钥是公开的，用私钥加密的信息，可以用公钥对
其解密，用于客户验证持有私钥一方发布的数据或文件是完整准确的，接收者由此可知这条信息确实来自于拥有私钥的某人，这被称作数字签名，公钥的形式就是数
字证书。例如，从网上下载的安装程序，一般都带有程序制作者的数字签名，可以证明该程序的确是该作者（公司）发布的而不是第三方伪造的且未被篡改过（身份
认证/验证）。
refer:
加密后的hash值
这里主要解释一下签名，签名就是在信息的后面再加上一段内容，可以证明信息没有被
修改过，怎么样可以达到这个效果呢？一般是对信息做一个hash计算得到一个hash值，注意，这个过程是不可逆的，也就是说无法通过hash值得出原来
的信息内容。在把信息发送出去时，把这个hash值加密后做为一个签名和信息一起发出去
指纹算法 即 一个hash算法 ，例如md5算法；
注意，为了保证安全，在证书的发布机构发布证书
时，证书的指纹和指纹算法，都会加密后再和证书放到一起发布，以防有人修改指纹后伪造相应的数字证书。这里问题又来了，证书的指纹和指纹算法用什么加密
呢？他们是用证书发布机构的私钥进行加密的。可以用证书发布机构的公钥对指纹和指纹算法解密，也就是说证书发布机构除了给别人发布证书外，他自己本身也有
自己的证书。证书发布机构的证书是哪里来的呢？？？这个证书发布机构的数字证书(一般由他自己生成)在我们的操作系统刚安装好时(例如windows
xp等操作系统)，这些证书发布机构的数字证书就已经被微软(或者其它操作系统的开发机构)安装在操作系统中了，微软等公司会根据一些权威安全机构的评估
选取一些信誉很好并且通过一定的安全认证的证书发布机构，把这些证书发布机构的证书默认就安装在操作系统里面了，并且设置为操作系统信任的数字证书。这些
证书发布机构自己持有与他自己的数字证书对应的私钥，他会用这个私钥加密所有他发布的证书的指纹作为数字签名。
refer:
数字签名是什么？
使用密码登录，每次都必须输入密码，非常麻烦。好在SSH还提供了公钥登录，可以省去输入密码的步骤。
所谓"公钥登录”，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。
这种方法要求用户必须提供自己的公钥。如果没有现成的，可以直接用ssh-keygen生成一个：
$ ssh-keygen
refer:
localhost：客户端，
remotehost：服务器
密钥访问：localhost
通过ssh-keygen来生成公钥密钥对，如果他想访问一个remotehost，则只需要将公钥添加到
remotehost的~/.ssh/authorized_keys中，接下来，当localhost通过ssh登录
username@remotehost时，remotehost会生成一个随机数，通过autrorized_keys中的公钥们生成一系列数值发给
localhost，localhost会通过自己的私有密钥解密发过来的一系列数值（当然，只有用对应的公钥生成的数值才会被正常解密），随
后，localhost将解密后的数值发回去，remotehost若发现发回来的数值是原先产生的随机数时，便会允许该localhost访问。当然，
如果localhost生成的rsa密钥是需要密码的话，接下来还要输入该密码。
refer:
从客户端来看,SSH提供两种级别的安全验证：
第一种级别是基于口令的安全验证:
（1）远程主机收到用户的登录请求，把自己的公钥发给用户。
（2）用户使用这个公钥，将登录密码加密后，发送回来。
（3）远程主机用自己的私钥，解密登录密码，如果密码正确，就同意用户登录。
缺点：如果有人冒充服务器，就会给你假服务器公钥，最后就能获得你回应的密码，这就是中间人攻击。
第二种级别是基于密匙的安全验证：
前提：客户端创建一对公钥+秘钥，同时将公钥放在服务器上。
1.客户端软件就会向服务器发出请求，请求用你的密匙进行安全验证；
与第一种级别相比，第二种级别不需要在网络上传送口令。第二种级别不仅加密所有传送的数据，而且“中间人”这种攻击方式也是不可能的（因为他没有你的私人密匙）。但是整个登录的过程可能需要10秒，但是相比输入密码的方式来说10秒也不长。
refer:
所谓的公钥认证，实际上是使用一对加密字符串，一个称为公钥(public key)，任何人都可以看到其内容，用于加密；另一个称为密钥(private key)，只有拥有者才能看到，用于解密。通过公钥加密过的密文使用密钥可以轻松解密，但根据公钥来猜测密钥却十分困难。
ssh 的公钥认证就是使用了这一特性。服务器和客户端都各自拥有自己的公钥和密钥。为了说明方便，以下将使用这些符号。
Ac 客户端公钥
Bc 客户端密钥
As 服务器公钥
Bs 服务器密钥
在认证之前，客户端需要通过某种方法将公钥 Ac 登录到服务器上。
认证过程分为两个步骤。
会话密钥(session key)生成
客户端请求连接服务器，服务器将 As 发送给客户端。
服务器生成会话ID(session id)，设为 p，发送给客户端。
客户端生成会话密钥(session key)，设为 q，并计算 r = p xor q。
客户端将 r 用 As 进行加密，结果发送给服务器。
服务器用 Bs 进行解密，获得 r。
服务器进行 r xor p 的运算，获得 q。
至此服务器和客户端都知道了会话密钥q，以后的传输都将被 q 加密。
认证
服务器生成随机数 x，并用 Ac 加密后生成结果 S(x)，发送给客户端
客户端使用 Bc 解密 S(x) 得到 x
客户端计算 q + x 的 md5 值 n(q+x)，q为上一步得到的会话密钥
服务器计算 q + x 的 md5 值 m(q+x)
客户端将 n(q+x) 发送给服务器
服务器比较 m(q+x) 和 n(q+x)，两者相同则认证成功
refer:
服务器建立公钥： 每一次启动 sshd 服务时，该服务会主动去找 /etc/ssh/ssh_host* 的文件，若系统刚刚安装完成时，由于没有这些公钥，因此 sshd 会主动去计算出这些需要的公钥，同时也会计算出服务器自己需要的私钥
客户端主动联机请求： 若客户端想要联机到 ssh 服务器，则需要使用适当的客户端程序来联机，包括 ssh, putty 等客户端程序连接
服务器传送公钥给客户端： 接收到客户端的要求后，服务器便将第一个步骤取得的公钥传送给客户端使用 (此时应是明码传送，反正公钥本来就是给大家使用的)
客户端记录并比对服务器的公钥数据及随机计算自己的公私钥： 若客户端第一次连接到此服务器，则会将服务器的公钥记录到客户端的用户家目录内的 ~/.ssh/known_hosts 。若是已经记录过该服务器的公钥，则客户端会去比对此次接收到的与之前的记录是否有差异。若接受此公钥， 则开始计算客户端自己的公私钥
回传客户端的公钥到服务器端： 用户将自己的公钥传送给服务器。此时服务器：具有服务器的私钥与客户端的公钥，而客户端则是： 具有服务器的公钥以及客户端自己的私钥，你会看到，在此次联机的服务器与客户端的密钥系统 (公钥+私钥) 并不一样，所以才称为非对称加密系统
开始双向加解密： (1)服务器到客户端：服务器传送数据时，拿用户的公钥加密后送出。客户端接收后，用自己的私钥解密 (2)客户端到服务器：客户端传送数据时，拿服务器的公钥加密后送出。服务器接收后，用服务器的私钥解密，这样就能保证通信安全
refer:
SSH 协议与OpenSSH详解 - Share your knowledge … - 51CTO技术博客
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
SSL/TLS协议(HTTPS 也是这样的)的基本过程是这样的:
1.客户端生成【随机数1】，客户端（通常是浏览器）先向服务器发出加密通信的请求，发送【随机数1】，向服务器端索要公钥； 2.服务器收到客户端请求后，生成【随机数2】，向客户端发出回应，回应信息包括【随机数2】，服务器证书(包含公钥) 3.客户端收到后，验证服务器证书的有效性，取出公钥，生成【随机数3】，使用公钥加密【随机数3】，发给服务器。 4.服务器回应， 至此，服务器和客户端都有3个随机数，使用3个随机数生成这次的会话秘钥(即对称秘钥)，二者开始使用对称加密通讯。服务器通知客户端：编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验(对称加密)。 5.之后二者将通过对称加密来通讯。
解释：为啥使用3个随机数。
不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性，三个随机数通过一个密钥导出器最终导出一个对称密钥，增加随机性
之前很多讲HTTPS原理的(包括下面的https)，都只有1个随机数，为啥？因为毕竟是讲原理，并没有讲清细节；
简单来说，一开始使用的非对称加密，就是为了安全的传递对称秘钥，毕竟对称加密的速度快。
refer:
refer: