加密基础

所谓的加密

加密就是发送方把有意义的一系列 明文,通过某种方式 转换 成没有任何意义的 密文。只有信息接受方知道 密文 的转换方式,逆转回有意义的 明文,已达到对不知道这系列转换方式的人隐藏信息的目的。

举个简单的例子:
密文: Ifmmp,xpsme.
转换方法:字母表往后推 N 个字母;空格和逗号互换;句号和感叹号互换。
关键 N 取值:1
逆推下,获得了明文:
Hello world!

以上例子就是个简单的对称加密。Hello world! 为明文信息;转换方法对应的,就是对称加密中的加密算法;关键N取值 对应的 密钥Ifmmp,xpsme. 为加密完成后的密文。

加密类型

常用的加密算法,根据密钥数量来分,有3种

杂凑(hashing)算法 —— 没有密钥

也称哈希算法或者映射算法。此类算法严格意义上,不算加密算法,因为此算法无法将密文数据解密还原为明文。他只是数据单向映射。能把一个长数据,映射成固定长度的较短数据,当数据内容发生了变化时,映射出来的数据,也同样发生改变。此类算法一般用于签名,防止,或者说辨别数据是否被篡改过。由发送方将数据按一定排序规则,进行拼接,然后计算签名。当接收方接收到数据时,把数据按同样的排序规则拼接,计算签名,对比发送方发送过来的签名,看是否一致。

  • 一般为了签名的可靠性,除了数据信息外,还会额外拼接约定好的一个签名信息;或者数据信息拼接完成后,使用其他加密算法进行加密后,再映射。已确保签名无法通过 已知信息生成。

例如:
发送数据

{"name":"abc","id":"1234"}

约定签名内容为:key按字母顺序排序后,拼接value;最后拼接签名信息:ccwork
即,签名内容:1234abcccwork,假设签名结果为:BC697640
即,最后发送的报文为:

{"name":"abc","id":"1234","sign":"BC697640"}

接收方接收到数据后,按同样的签名内容拼接方式凭借完数据后,对比sign字段,看是否一致
若是篡改方,则会因为无法获知拼接方式和最后的固定签名信息,而无法篡改出一个合法的签名信息,从而保证了数据的可信度

  • 此处签名信息,有时也会被称为签名密钥,单它并非传统意义上的密钥,不起到加解密作用,只用于修改数据内容,校正签名信息

哈希算法的主要作用是压缩数据,只保证数据的完整性(只有一样的原数据可以压缩出同样的映射数据),不保证数据的可靠性(所有人都知道算法,都可以压缩数据)

使用场景

  • 文件完整性校验,常用算法:MD5,crc32 等。常用与校验网络传输过程中是否出现偏差,导致下载的文件有所损坏。
  • 数据签名,常用算法:sha256、SM3 等。用于数据签名时,哈希算法只起到压缩数据长度作用,安全性和可靠性需要通过另外手段保证(如例子中提到的额外签名数据等)。
  • 密码存储,常用算法:sha1、MD5 等。一般密码是需要用户手动输入校验的,但存储无需知道具体密码,只需要校验用户输入密码的完整性即可。

对称加密 —— 一个密钥

此类算法拥有一个固定密钥。加密方通过这个密钥对数据进行加密。解密方通过同样的密钥对加密过的数据进行逆运算,解密恢复原数据。
大多数情况下,通信安全都是由对称加密来保证的。对称加密的算法相对(非对称加密)来说计算损耗较小。
还是紧接着上面的例子

{"name":"abc","id":"1234","sign":"BC697640"}

如果第三方直接拦截了报文,很容易就能得到"name":"abc","id":"1234" 的信息。这部分信息,可以通过对称加密,进行处理。直接将{"name":"abc","id":"1234"} json 字符串,加密处理,例如结果为:07D1C662F8CB1550E8934E5444158D2912883E8BBC08CB590B306E3DC061B5DA,并放置在 content 字段中;重新拼接并计算签名值,最后形成报文如下:

{"content":"07D1C662F8CB1550E8934E5444158D2912883E8BBC08CB590B306E3DC061B5DA","sign":"6D22322A"}

在上面的报文中,即便被第三方拦截,也无法直观地解析出数据内容。达到了通信安全的目的。
如果通信双方是固定的,那可以约定一个固定的密钥。但这个密钥一旦被破译,则后续通信都不安全。如何动态地约定一个通信密钥,是对称加密通信的一个难点。

对称加密的主要作用是保证数据的可靠性(只有知道密钥的双方可以对信息进行加解密),但密钥的约定是个难题

使用场景

  • 通信数据加密,常用算法:AES、SM4 等。
  • 本地数据持久化存储,常用算法:DES、DES3 等。

非对称加密 —— 两个密钥(公私钥)

此类算法拥有两个固定密钥:公钥 —— PK,public key,是公开给所有通信端的;私钥 —— SK,signing key 也称 private key,只有自身知道的一个密钥。
非对称算法涉及到的数学知识比较高深,但作为使用方而非实现方来说,只需要知道以下定律就行了

  • 公私钥为一对一的关系,且私钥可以计算出公钥,而公钥无法反推私钥
  • 公钥加密过的信息,可以通过私钥解密还原;私钥加密过的信息,也可使用公钥解密还原
  • 公钥加密的信息,公钥无法解密还原

非对称密钥经常用于解决对称加密中密钥传递的问题。主要因为其计算较为复杂,耗费性能。

使用场景

  • 公钥加密 + 私钥解密,保证密文安全
  • 私钥签名 + 公钥验签,保证来源可靠
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,864评论 6 494
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,175评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,401评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,170评论 1 286
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,276评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,364评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,401评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,179评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,604评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,902评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,070评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,751评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,380评论 3 319
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,077评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,312评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,924评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,957评论 2 351

推荐阅读更多精彩内容