码迷,mamicode.com
首页 > 编程语言 > 详细

加密类型及其相关算法

时间:2016-12-19 14:56:10      阅读:230      评论:0      收藏:0      [点我收藏+]

标签:linux

加密类型及其相关算法

·互联网通信所面临的的安全问题

    现如今我们在互联网上进行数据的通信所面临的的安全问题一般具有如下的三个特征:

        1,机密性

        2,数据的完整性

        3,身份验证

一,机密性

    我们在互联网上进行数据的传输,如何保证我们所传输数据的机密性呢?所谓机密性就是给我们所传输的数据进行加密,加密本身其实就是一种转换规则,通过这种转换规则可以将我们所要传输的数据转换为一些杂乱无章的很难识别出来的数据,转换之前的数据我们称为明文(plaintext),转换后的数据我们称为密文(ciphertext),一定是按照某种转换算法来实现加密的:

                plaintext --> 转换算法 --> ciphertext

    那么接收方接收到密文数据的时候,如何查看这段被加密的数据呢?这就是一个解密的过程,解密仍然使用和加密一样的转换规则,即将密文还原为明文的过程,我们称为解密:

                ciphertext --> 转换算法 --> plaintext

    但是仅仅通过一些转换算法来对我们所要传输的数据进行加密,其实是很不安全而且很麻烦的,因为我们明文和密文之间的转换规则很容易被其他人得到,这样我们的机密性得不到保证,此时我们可以通过给转换规则加密来保证数据的机密性,给转换算法加密的密码我们称之为密钥。

    1,密钥

    保证数据机密性最核心的不是转换算法本身而是密钥,我们得依靠密钥来保证数据的机密性,就算被其他人得到了我们的转换算法如果他们没有密钥,也没有办法进行解密,并且我们可以通过频繁的更换密钥来保证这种机密性,因为对我们来说更换密钥是很容易的,但是更换一种算法却是很难的,实现数据机密性的最早加密的方式,我们称之为对称加密。

    2,对称加密

    对转换规则的加密和解密使用的是同一个密钥的加密方式叫做对称加密,对称加密方式一般会有加密算法和解密算法,但是对转换算法加密使用的是同一个密钥,对称加密的好处在于算法的计算速度非常的快,但是对称加密方式的机密性几乎完全依赖于密钥,对称加密方式在一定程度上解决了数据机密性的问题,但是却无法帮助我们用户去解决密钥的有效管理的问题,如果我们同时与多台主机进行数据通信,我们的主机就得维护多个密钥,这是非常麻烦的。

二,数据的完整性

    数据的完整性指的是保证我们在互联网上传输的数据本身不会其他人恶意的篡改,数据的完整性我们可以使用单向加密方式来保证。

    1,单向加密

    单向加密是一种提取数据特征码(又叫做数据的指纹,每一个数据的特征码都是不同的)的方式,单向加密的过程大致如下:

    收发双方在进行数据通信之前,发送方首先会使用单向加密的相关算法将要发送的数据的特征码计算出来并提取出来附加在要发送的数据的后面,并且将二者一并发送给接收方,接收方在接收到数据之后会使用相同的算法计算数据的特征码,然后将计算出来的特征码和发送方发送过来的特征码进行比较,如果特征码一致,那么就证明数据没有被篡改,如果不一致说明数据本身在传送的过程中遭到了篡改,接收方可以拒绝接收,以此来验证数据传输过程中的完整性。

    单向加密算法的特性:

        1,输入一样,输出必然一样

            表示数据本身如果一样,那么计算出来的数据特征码必然一样,就好像我们人一样,每一个人的指纹信息都是不会改变的。

        2,雪崩效应

            输入的微小改变,将会引起输出的巨大变化,主要用来避免被人恶意的破解数据特征码。

        3,定长输出

            表示无论数据本身有多大,计算出来的数据特征码的长度都是一样的,通俗的理解就是无论一个人的体重有多大,指纹大小一般都是相同的。

        4,不可逆

            即无法根据特征码恢复出原始数据本身,故这种加密方式被称之为单向加密。

    所以当我们使用单向加密的方式的时候,只需要比较发送方发送到接收方的特征码和接收方自己计算出来的特征码就可以了验证数据的完整性了,但是数据如果不完整却是由三方面的原因造成的:

        1,发送方发送的数据本身在传送的过程中没有发生任何改变,但是由于传送过程电器信号的原因导致特征码发生了改变,这是由于特征码的错误导致了数据的不完整,但是我们的数据本身还是完好的。

        2,特征码没有发生错误,但是数据本身发生了错误

        3,数据本身和特征码本身都发生了错误

        无论是上述哪一种原因造成的数据的不完整,接收方一概不予接收,而且数据的完整性无法避免中间人攻击,假设发送方在向接收方发送附加有数据特征码的数据的时候,这时有一个在收发双方之间的恶意中间人将这段数据截获下来,由于我们的数据本身并没有加密,那么任何截获我们数据段的人都可随意修改我们的数据本身,之后再生成一个篡改后的数据特征码附加在篡改后的数据后面发送给接收方来冒充我们的发送方,这样一来我们的数据的完整性也无法得到保证,这是由于我们没有进行身份验证而造成的的数据不完整,所以我们还得依靠其他方式来保证数据的完整性,这种方式就是给数据特征码进行加密处理,我们先来大致的说一下这种机制:

        发送方在发送数据之前,会先给数据特征码进行密钥(保证这个密钥除了发送方任何人都无法获取到)加密,之后接收方会利用一个对应的密钥给特征码进行解密,如果可以解密,那么说明该段数据就是发送方发送过来的,这就完成了发送方的身份验证,即使这个时候存在中间人攻击,那么这个恶意中间人即便是截获到我们这段数据,并将我们的原始数据恶意篡改,并生成了一个新的数据特征码,它也只能使用自己的密钥重新对特征码进行加密(因为收发双方加密和解密特征码的密钥是事先就协商好的),但是这个它自己的密钥,发送到接收方那里,接收方是无法使用对应的密钥进行解密的,此时接收方就不会接受这份数据,这就间接的保证了我们的数据的完整性,所以说单向加密的方式还得依靠加密密钥的方式来保证数据的完整性,但是这里面有一个问题,如果我们收发双方是如何事先协商好加密和解密密钥的呢,也就是说它们是如何完成这个密钥约定的呢?事实上我们可以使用一种叫做密钥交换的机制来完成这种密钥约定。

    2,密钥交换

    密钥交换机制需要特殊的互联网协议来支撑,最早的,也是今天被当做基本密钥交换算法的或者密钥交换机制的密钥交换协议叫做Deffie-Hellman算法或者是Deffie-Hellman协议,这是一种密钥交换协议。

    3,IKE(Internet Key Exchange)

    互联网密钥交换,Deffie-Hellman算法就是著名的互联网交换协议。

    4,Deffie-Hellman协议

    该协议实现密钥交换的机制:

        收发双方为了进行通信,发送方在进行通信之前会先在本地选择三个数字,首先选择一个大素数(素数或质数->只能被1和它本身整除的数)p,这个数很大,利用离散对数原理,然后再选择一个生成数g(generator),p和g在互联网上传输,任何人都可以看到,但是接下来,发送方和接收方分别在本机内部生成一个随机数x和y并且不在互联网上传输这两个数字,而且x只有发送方知道,y只有接收方知道,接下来收发双方开始进行计算,并且发送方将g的x次方对p取模的结果g^x%p发送给接收方,接收方将g的y次方对p取模的结果g^y%p发送给发送方,此时我们在互联网上仅仅只传输了四个数字p、q、g^x%p以及g^y%p,就算有人将这四个数字截获下来也无法推算出x和y得具体值是多少,这是因为离散对数原理的存在,但是这个时候收发双方将这个计算结果接收到之后,在这个计算结果的基础上再进行一次计算,发送方对这个结果取x次方得(g^y%p)^x=g^yx%p,接收方对这个结果取y次方得(g^x%p)^y=g^xy%p,得到的计算结果是相同的虽然我们在互联网上传输了四个不同的数字,但是最终收发双方得到的计算结果却是相同的,这个最终的结算结果就是最后的密钥,这就是著名的Deffie-Hellman算法的密钥交换机制,因此有了这种机制收发双方就可以放心的进行通信了,收发双方不用实现约定好密钥是什么,因为让我们的加密密钥在互联网上进行传输实在太不安全,我们只需要选定一些数字在互联网上传输,并将这些数字的计算结果当做我们互相进行通信所使用的密钥,Deffie-Hellman算法的好处在于收发双方从此不需要再记忆密钥,我们可以利用一些软件,该软件可以利用Deffie-Hellman算法,在收发双方每一次进行通信的时候都重新计算并重新交换密钥,就算有人恶意破解出我们的加密密钥,但是下一次通信的时候密钥已经改变了,该软件可以在收发双方彼此通信之前通过Deffie-Hellman算法来交换密钥,而且生成的密钥是由这个软件自身进行管理的,收发双方不用关心密钥到底是什么,并且数据的完整性也是由该数据完成验证的,收发双方只需要生成数据和数据特征码即可,但是这种机制还是无法完全避免恶意的中间人攻击,所以我们现在面临的最大问题就是该死的中间人攻击,总的来说中间人攻击就是我们无法验证收发双方的身份,所以我们接下来要解决的就是如何进行身份验证。

三,身份验证

    我们在互联网上进行通信时的身份验证的需求,又催生了第三种加密方式,非对称加密也叫做公钥加密的方式,非对称加密的特征:

    密钥是成对的,称为密钥对。

    1,密钥对

        ->公钥p(public key)

            任何人都可以看到的key,在非对称加密中,公钥不是独立的,公钥是从私钥中提取出来的,公钥来自于私钥,所以为了保证非对称加密的安全性,私钥都会非常的长,公钥是根据某种机制能够完全从私钥中提取出来的,所以公钥加密算法的密钥是成对出现的,用公钥加密的数据只能使用与之对应的私钥进行解密,反之亦然。

        ->私钥s(secret key)

            只有本地主机自己知道的key。

    如何收发双方都使用公钥加密算法来进行通信的话,发送方会使用自己的私钥对要发送的数据进行加密,由于公钥是公开的,任何人都可以得到,所以这种加密方式无法保证数据的机密性,但是却可以达到身份验证的效果,每一方使用自己的私钥对所要发送的数据进行加密可以保证数据传输过程中的身份验证,发送方使用自己的私钥对数据进行加密可以进行身份验证,发送方使用接收方的公钥来对数据进行加密可以达到数据机密性的效果,公钥加密算法很少拿来进行保证数据的机密性,因为公钥加密算法的速度太慢了,因为密钥太长,一般来讲公钥加密算法要比对称加密算法加密数据的速度慢上3个数量级,公钥加密算法一般用在需要进行身份验证的场合,所以收发双方一般会将单向加密算法和公钥加密算法结合起来使用分别来保证数据的完整性和身份验证,这个时候的通信过程是这样的:

    发送方在生成了要发送的数据之后,在发送之前会先计算该段数据的特征码,并将特征码附加在该段数据后面,之后发送方会使用自己的私钥去加密特征码,之后再将整段数据都发送过去,整段数据中数据本身还是明文的,只有特征码是被加密的,如果不幸整段数据又被恶意中间人截获,那么我们的数据本身还是可以被篡改,但是篡改之后恶意中间人只能使用自己的私钥重新加密特征码,在接收方接收到这段被篡改的数据之后,接收方会首先使用发送方的公钥来对特征码解密,如果不能解密,说明这段数据不是发送方发送过来的,接收方就拒绝接收,这样就满足了身份验证的需求,如果可以解密特征码,那么就说明发送方的身份得到了验证,接着接收方再根据计算特征码和发送方发送过来的特征码进行比较来验证数据的完整性,此时数据的完整性和身份验证的需求就都得到了保证,事实上非对称加密的主要作用就是用来进行身份验证。

    但是由上面的描述可以知道,我们通信过程中所有的保证都是依赖于发送方的公钥,那么接收方是如何获取到发送方的公钥呢?众所周知,发送方的密钥对是自己计算生成的,别人是如何获取到它的公钥的呢?其实是接收方主动获取的,收发双方在进行通信之前,首先接收方会向发送方发起通信请求,但是在这之前接收方需要确认它所要建立通信的发送方就是发送方,这个确认的动作该如何进行呢?这时需要一个第三方机构来帮助我们进行发送方的身份验证,这个第三方机构就是发证机构,因此收发双方为了在互联网上能够安全可靠的使用身份验证的形式进行通信,就得依靠发证机构。

    2,发证机构

        首先在收发双方进行通信之前,发送方会首先在自己的主机内部生成一个密钥对s/p,为了保证自己的公钥的可信度,发送方会先将自己的公钥发送给发证机构,由发证机构对它的公钥进行公证,发证机构会给发送方的公钥生成一个数字证书,数字证书里面的信息都包括发送方主机的地址,主机上的用户名,发送方的公钥信息等等,但是最最重要的信息是发证机构的证明信息,该证明信息保证了发送方的身份已经被发证机构所认可,发送方就是发送方本身,这个证明信息就叫做数字签名,这个数字签名是发证机构将发送方的相关数据信息计算特征码之后并用发证机构的私钥对特征码进行加密的结果,一个数字证书有了数字签名才算是一个完整的数字证书,整个具体的验证过程是这样的:

        发证机构会首先给自己生成一个自己的证书,发证机构会先生成自己的s/p,之后再将自己的公钥做成证书(certificate),生成了自己的证书之后,会将发送方发送给它的数据进行数据特征码的计算,并将计算出来的特征码使用发证机构自己的私钥进行加密,故该段被加密的特征码只有发证机构的公钥才能够解密,这样发送方就相当于是向发证机构申请了自己的证书,同时接收方会利用同样的方法向发证机构申请自己的证书,接下来就是收发双方正式开始通信的时候了:

        首先由接收方向发送方发起通信请求,然后发送方会将自己的数字证书发送给接收方,该证书里面包含有发送方的公钥信息等数据,之后发送方将自己生成的数据计算出特征码,并使用自己的私钥加密这段特征码,完成之后将整个数据段发送给接收方,接收方就可以根据证书中的公钥信息对这段数据的特征码进行解密了,但是接收方如何认可发送方发送给它的证书呢?因此收发双方必须有一个双方共同认可的发证机构,接收方认可该证书的前提必须是发送方也认可这个第三方的发证机构,那么接收方如何认可这个第三方的发证机构呢?我们先前说过数字签名的中的信息的特征码是被发证机构的私钥进行加密的,那么如果接收方使用发证机构的公钥能够解密这段信息的特征码,那么说明该证书是发证机构所发,接下来使用解密后的特征码来验证证书数据信息的完整性,如果没有问题的话,那么发送方的身份就得到了验证,同样发送方的公钥信息的可靠性也就得到了保证,此时通信就可以正常进行了,但是由上面的描述我们又引入了一个新的问题,那就是我们如何获取发证机构的公钥?

        花钱买! 

        我们上面的所有解决方案都很好的解决了数据的完整性和身份验证的问题,但是还是无法保证数据的机密性,为了保证数据的机密性,并且为了使得加密的速度不会特别的慢,我们得使用对称加密的算法。

        于是乎,现代互联网中为了实现安全可靠的通信过程是这样的:

        在收发双方进行通信之前,它们会分别依靠发证机构获取对方的数字证书,接下里发送方开始生成将要发送的数据,并计算出该段数据的特征码(数据的完整性),然后使用自己的私钥对这段特征码进行加密(身份验证),接下来发送方会在自己的主机内部生成一个随机数,使用该随机数给我们的数据和加密的特征码整体进行加密,最后使用接收方的公钥对这个随机数进行加密并附加在整体数据段的后面(数据的机密性),并将这一个大整体全部发送给接收方,接收方在接收到这段数据之后会先使用自己的私钥对被加密的随机数进行解密,之后利用这个随机数对整体数据段进行解密(数据的机密性),接下来会使用发送方的公钥对加密的数据特征码进行解密(身份验证),最后在自己的主机内部使用相关算法计算出原始数据的特征码,并和发送方发送过来的数据特征码进行比较(数据的完整性),于是乎数据的机密性、完整性以及身份验证就通通得到了保证。

    3,PKI(Public Key Infrastructure)

        公钥基础设施,是由根发证机构和隶属于它的子发证机构所组成的,PKI的核心就是证书(CA)颁发机构和它们彼此间的信任关系。


本文出自 “菜鸟的技术文档” 博客,请务必保留此出处http://zhubo.blog.51cto.com/11395641/1883893

加密类型及其相关算法

标签:linux

原文地址:http://zhubo.blog.51cto.com/11395641/1883893

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!