Openssl及加密解密(一)数据加密解密及CA原理

本文涉及的产品
密钥管理服务KMS,1000个密钥,100个凭据,1个月
简介:

明文:plaintxt或者cleartext,也就是没有加密的,直接可以看懂的内容。密文就是通过特殊方式处理过的内容,无法直接看懂。

常见的加密方式:

  • 对称加密

  • 公钥加密

  • 单向加密

加密原理:将原文按固定大小切割成数据块,逐个数据块进行加密,因为逐字符加密的速度太慢了。在加密是通常把第一个块加密,然后再把第二个块加密,输出的第二个块还不是加密以后的第二个块,而是将第一个块加密后的结果和第二个块加密后的结果做异或操作作为第二个块的输出,所以你每拿到一个块之后要想还原就必须拿到前一个块,来做异或操作。


秘钥交换(IKE):DH算法。也就是在秘钥交换过程中没有发送任何密码,A经过计算生成一些数据给了B,B自己再生成一些数据传给A,A和B拿着对方给的数据经过计算得出口令,而且这个口令是一样的。


对称加密:

加密算法+口令,把要转换的数据也就是明文数据,通过加密算法内部转换明文变成密文。这个算法可能是公开的,但口令只有你自己知道。为了更加安全,那么加密本身不能过于依赖算法,因为算法固定而且一旦算法遭到破解,那么基于这个算法的所有密文都可以破解,所以算法固然重要,但是最重要的是口令,口令可以变,就算算法破解了,口令不知道也是没有用的。对称加密是加密和解密都使用相同的口令。比如DES(56bits)、AES(128bits)、AES(192bits)、AES(256bits)、3DES。

对称加密有个问题,算法对方可以拿到,但是口令呢?所以这是它最大的问题。如果通信涉及到多个方面而且口令不能使用相同的,那么你需要记录的密码就非常多。所以对称加密无法解决秘钥交换的问题,还有我给你密码如何保证收到密码的就是你也就是认证问题,另外就是别人截获密文然后做了修改收到的人解密后信息不对但是他并不知道这就数据完整性问题。

公钥加密(非对称加密):

相对于对称加密而言,公钥加密是非对称加密,它会生成公钥和私钥,公钥可以给任何人是公开的,A使用B的公钥进行加密,B使用自己的私钥进行解密。它解决了对称加密中需要记录众多口令的问题。但是公钥加密的密码长度很长,早期的512位到现在的2048位,这种加密方式造成加密速度很慢所以公钥加密一般不用来加密数据,而是用来加密口令,数据还是用对称加密。A生成口令加密数据,然后用B的公钥加密口令,然后把加密后的口令和数据传递给A,A用私钥解密口令,得到口令后再用口令解密数据。常用的公钥加密算法:RSA、DSA、DES、AES

这个过程也实现了秘钥交换过程,同时它还可以实现用户身份的认证即发信息的人是它声称的人,它是这么实现的,A用自己的私钥加密,如果要想解密就只能使用A的公钥,虽然公钥任何人都能获得,但是你用A的公钥一旦解密了信息,就证明这个信息是用A的私钥加密的,只有A才有A自己的私钥,所以就证明了发信息的这个人就是A。这时候你会想到,用自己的私钥加密数据那不等于没加密一样么,因为公钥谁都可以得到。再说公钥加密算法速度慢,用私钥加密也一样。所以通常都在引入另外一种方式,也就是单向加密。

单向加密:

单向加密可以保证数据完整性,经过加密的数据如何保证不被篡改,它本身不是一种加密技术而是一种不可逆的抽取数据指纹的技术,常见的有MD5、SHA1、SHA512、CRC32等。那么如果篡改了如何发现?A对数据抽取一段使用单向加密来获取特征码,也叫指纹信息。但是如何保证指纹信息不被篡改和重新生成呢?这就是上面说的和公钥加密结合。A抽取数据一段进行单向加密,生成特征码,然后用自己的私钥加密特征码,发送给B,这时候C截获了数据,然后使用A的公钥解密了特征码,然后再篡改了数据,这时候C再想加密特征码而他没有A的私钥所以C只能用自己的私钥加密特征码,当B收到数据以后,B使用单向加密获取数据的特征码,然后用A的公钥来解密发过来的加密特征码,显然无法成功,假设C没有篡改特征码而是修改的数据,那么B使用单向加密获取数据特征码,然后用A的公钥解密加密的特征码,两者一对比肯定不一样。虽然上述过程没有考虑数据本身的加密,但由于可非对称加密结合,实现了秘钥交换、身份验证、数据完整性,但无法保证数据私密性。那如何同时实现数据加密、数据完整性和身份认证呢


那如何同时实现数据加密、数据完整性和身份认证呢

三种方法融合在一起

  1. A生成原始数据,使用单向加密计算数据特征码(保证数据完整性),然后用A自己的私钥加密特征码(保证身份验证)

  2. A再找一个密码,用对称加密算法把数据、特征码整体加密(实现了对数据的加密,因为对称加密算法速度快)

  3. A再使用B的公钥,第二不中的对称加密算法中的密码进行加密。

  4. 上述三步完成后,发送给B。

第三方如果截获了数据,它没有B的私钥所以无法获得解密数据的密码,从而无法解密数据。下面是B获得数据后的步骤:

  1. B使用自己的私钥解密获取密码(因为只有自己的私钥才可以解密,证明是发给自己的,实现了秘钥交换)

  2. B使用获得的对称加密密码进行解密数据(原始数据和数据特征码),(实现了数据加密和解密)

  3. B使用A的公钥解密特征码,然后使用单向加密算法计算数据特征码(实现了身份验证,因为只有A的公钥才能解密A的私钥加密的数据)

  4. 对比解密后的特征码和计算后的特征码,如果一致说明数据没有篡改(实现了数据完整性)


上面的过程看似完美,但实际上还有很大漏洞,A发送给B之前肯定向B索取B的公钥,而且A拿到之后必须要相信这个公钥就是B的,但如果C截取了信息,C把自己的公钥给了A,并声称自己是B,那么A是无法验证的,同样C也依然可以冒充A。所以整个过程最薄弱的环节就是交换公钥的环节。为了解决这个问题这就是需要第三方机构,也就是我们要说的CA。那么申请方向CA提交信息进行审核其中最重要的是公钥,审核通过后CA会把产生一个证书,之后把证书发给申请方。为了避免证书发送过程中伪造,则CA会计算申请者提交信息的特征码,然后用自己的私钥(CA自己的证书是自己给自己颁发的)进行加密后一起发送给申请方。申请方用CA的公钥解密,如果成功就证明是CA发的。CA对特征码进行加密就是电子签名。

这时候A要给B通讯,A向B要证书(证书中包含B的公钥,当然也可以同时包含公钥和私钥),然后A去CA获取CA的公钥,然后用公钥解密证书的数字签名得到特征码,如果成功就证明证书是CA颁发的且没有被篡改。但这里又出现上面的问题,A向CA索要公钥,万一有人冒充CA怎么办?这就是在操作系统中内置全球知名CA的公钥。你只要是通过正规渠道获取的正版系统,那么所包含的公钥都是真实可靠的。


PKI(Public Key Infrastucture):公钥基础设施,公钥发放吊销等机制。


上面都是概念,而实现这些概念的软件常用的就是openssl、gpg.



      本文转自linuxjavachen  51CTO博客,原文链接:http://blog.51cto.com/littledevil/1924650,如需转载请自行联系原作者






相关文章
|
18天前
|
存储 安全 数据安全/隐私保护
Codota的数据加密技术包括静态数据加密和传输中的数据加密
Codota的数据加密技术包括静态数据加密和传输中的数据加密
42 4
|
17天前
|
安全 数据库 数据安全/隐私保护
对称加密与非对称加密的区别
对称加密与非对称加密的区别
177 64
|
9天前
|
Java 数据安全/隐私保护
对称加密、非对称加密、哈希摘要
对称加密使用同一密钥进行加解密,速度快但需保密;非对称加密采用公钥加密、私钥解密,公钥可公开,安全性高但速度较慢,双向通信需双方各持一对密钥;哈希摘要是从数据中提取特征,用于数据完整性校验,不同数据的哈希值几乎不会相同。
20 0
|
2月前
|
存储 安全 算法
网络安全与信息安全:构建数字世界的防线在数字化浪潮席卷全球的今天,网络安全与信息安全已成为维系现代社会正常运转的关键支柱。本文旨在深入探讨网络安全漏洞的成因与影响,剖析加密技术的原理与应用,并强调提升公众安全意识的重要性。通过这些综合性的知识分享,我们期望为读者提供一个全面而深刻的网络安全视角,助力个人与企业在数字时代中稳健前行。
本文聚焦网络安全与信息安全领域,详细阐述了网络安全漏洞的潜在威胁、加密技术的强大防护作用以及安全意识培养的紧迫性。通过对真实案例的分析,文章揭示了网络攻击的多样性和复杂性,强调了构建全方位、多层次防御体系的必要性。同时,结合当前技术发展趋势,展望了未来网络安全领域的新挑战与新机遇,呼吁社会各界共同努力,共筑数字世界的安全防线。
|
2月前
|
安全 网络协议 网络安全
【HTTPS】对称加密和非对称加密
【HTTPS】对称加密和非对称加密
37 0
|
3月前
|
算法 安全 网络安全
概念区分:对称加密、非对称加密、公钥、私钥、签名、证书
概念区分:对称加密、非对称加密、公钥、私钥、签名、证书
154 0
|
4月前
|
存储 算法 网络安全
二进制加密PHP Webshell原理及简单实现
二进制加密PHP Webshell原理及简单实现
130 8
|
5月前
|
缓存 网络协议 算法
(二)Java网络编程之爆肝HTTP、HTTPS、TLS协议及对称与非对称加密原理!
作为一名程序员,尤其是Java程序员,那必须得了解并掌握HTTP/HTTPS相关知识。因为在如今计算机网络通信中,HTTP协议的作用功不可没,无论是日常上网追剧、冲���、亦或是接口开发、调用等,必然存在HTTP的“影子”在内。尤其对于WEB开发者而言,HTTP几乎是每天会打交道的东西。
100 10
|
4月前
|
存储 算法 安全
|
4月前
|
安全 Nacos 数据安全/隐私保护
【技术干货】破解Nacos安全隐患:连接用户名与密码明文传输!掌握HTTPS、JWT与OAuth2.0加密秘籍,打造坚不可摧的微服务注册与配置中心!从原理到实践,全方位解析如何构建安全防护体系,让您从此告别数据泄露风险!
【8月更文挑战第15天】Nacos是一款广受好评的微服务注册与配置中心,但其连接用户名和密码的明文传输成为安全隐患。本文探讨加密策略提升安全性。首先介绍明文传输风险,随后对比三种加密方案:HTTPS简化数据保护;JWT令牌减少凭证传输,适配分布式环境;OAuth2.0增强安全,支持多授权模式。每种方案各有千秋,开发者需根据具体需求选择最佳实践,确保服务安全稳定运行。
393 0