既定需求A
在使用加密的典型场合中,双方(Alice 和 Bob)在不安全的信道上通信。Alice
和 Bob 想要确保任何可能正在侦听的人无法理解他们之间的通信。而且,由于
Alice 和 Bob 相距遥远,因此 Alice 必须确保她从 Bob 处收到的信息没有在
传输期间被任何人修改。 此外,她必须确保信息确实是来自 Bob,而不是来自模仿
Bob 的人。
加密用于达到以下目的:
保密性:帮助保护用户的标识或数据不被读取。 采取措施: 双向加密
数据完整性:帮助保护数据不被更改。采取措施: 单项加密(MD5散列)
身份验证:确保数据发自特定的一方。采取措施: 数字签名
不可否认性:防止特定的一方否认发送过消息。采取措施: 公钥加密
双向加密原理简析:
Alice 发送 "I Love You" 信息给 Bob,Alice不希望其他人看到此信息,此时她利用
双向加密完成对内容的处理. Alice 的加密密码是 aa,则此段信息变为"IaaLoveaaYou"
那么 Bob 拿到 Alice 的信息,指定密码 aa, Bob 就可以完成对原话的解密,此时双向
加密就显而易见了,用同一个密码加解密,这也就保证了加密的快速性.
你需要知道的加密算法
常见的双向加密: DES , 3DES , AES
openssl enc -in <要加密的file> -out <加密后的文件file> -e 加密 -des
openssl enc -in <要解密的file> -out <解密后的文件file> -d 解密 -des
既定需求B:
Alice 和 Bob 通信的时候,可能Evil在旁边盯着呢! Evil通过多重技术手段(自行脑补
http://wenku.baidu.com/view/1473d13a580216fc700afdf6.html)
拿到了Alice的原内容及加密密码,Evil灵机一动,将内容改动为 I F**K You,之后利用
加密密码aa加密,此时内容变为 IaaF**KaaYou,你猜Bob接收到信息会怎么样? 所以 Bob
接收到信息时要保证没有人修改过此内容.
单项加密原理简析:
I Love You 与 随机Hash值(11),1轮计算,当然在真实场景中是大于
128位的素数,计算可能是超过512轮次的,在这里只是为说明问题.
常见的单项加密: MD5 , SHA128 , SHA256 , SHA512
openssl dgst [-摘要类型] <作摘要的文件>
注意: 单项加密只是对原文信息的内容做了摘要,并没有对数据进行加密
既定需求C:
到目前为止在既定需求B中存在的两个问题,我们只解决了一个(保证完整性),加密传送过程
中需要传输密码,这显然不安全.我们尝试一下做法:不传输密码,做到密码的交换.
密钥交换(非对称加密)原理简析:
利用Diffle-Hellman密钥交换算法,只协商两个大素数,利用最基本的乘法分配,在本地
完成数据交换,避免了密码的网络传输.但DH算法无法抵御中间人攻击,必须借用数字签名
才足够安全.
常见的非对称加密啊: DH , IKE
struct
{
BIGNUM *p; // 大素数
BIGNUM *g; // 生成的质数
BIGNUM *priv_key; // 私有值x
BIGNUM *pub_key; // 计算值g的x次方
};
既定需求D:
通过既定需求B和C后,似乎密码安全可以得到保障,我们在试想一个问题,在 Alice与Bob
第一协商准备密码时, Evil 就已经冒名顶替了 Bob 该怎么办?在未来的通信中 Alice
将持续和 Evil 通讯,这当然违背了 Alice 的初衷.问题产生,谁能向 Alice 证明此时
与她通信的就是 Bob 呢???
数字证书,签名原理简析
数字证书在这里充当第三人角色,去淘宝买东西买家的钱是先放在支付宝里是一样的定位.
怎么证明信用卡是你消费的??因为有你的签名,数字签名就是利用你拥有的唯一码对你所
产生的互联网信息进行单项加密. 数字证书将证明信息的真伪性,数字签名将证明信息的
不可伪造性,因为只有你有那唯一码
常见的数字证书与数字签名: x509, pkcs 与 RSA , DSA
openssl 详见 apache2.4.9安装–https实现
自此我们解决了加密的四个目的,当然没有万无一失的安全措施,安全问题愈发严重的今天,
(CSDN,天涯明文密码,京东被拖库,阿里内部数据被盗,2000W开房数据,携程信用卡信息泄漏..)
我们还需多关注互联网安全,多传播互联网安全,这是每个从业者应尽的职责和义务.