編碼,加密,Hash

對稱加密

  • 使用祕鑰和加密算法對數據進行轉換,得到的無意義數據以爲密文;使用祕鑰和解密算法對密文進行逆向轉換,得到的數據即爲原數據。

在這裏插入圖片描述

​ 首先通過加密算法進行加密,然後在進行發送,目標收到密文後就會通過解密算法進行解密

  • 對稱加密對任何的二進制數據都可以進行加密。

  • 經典算法:DES,AES

    由於 DES 祕鑰太短,導致被棄用了,如果祕鑰太短就會導致容易破解,爲什麼呢?如果暴力進行破解,祕鑰的長度太短,就會導致這個祕鑰很快被試完,然後就會被破解。

    現在主流都是 AES 。這兩個都是對稱加密。

非對稱加密

使用公鑰對數據進行加密得到密文;使用私鑰對數據進行解密得到原數據。

在這裏插入圖片描述

和對稱加密不同的是:在非對稱加密中解密的時候用的還是加密算法,但是祕鑰卻不同了

例子:比如雙方要進行通信,通信的內容只有10 個字符,分別是 0,1,2,3,4,5,6,7,8,9。加密祕鑰:對每個字符+4,解密祕鑰:對每個字符 +6

發送消息:110

加密:554

解密:5+6 = 11,拿到溢出的就是1,中間的也一樣,最後面的就是 4+6 = 10,拿到後面溢出的就是 0,最後的結果就是 110。

當然這個是禁不起推敲的,但是他可以解釋非對稱加密的核心原理,其中最主要的就是溢出。如果不允許溢出,那麼非對稱加密就沒辦法玩了。

  • 問題:如果 A 和 B 通過非對稱加密來進行通信時沒有任何問題的,但是問題在於怎麼把祕鑰發送給對方呢?

在這裏插入圖片描述

如果 A 和 B 進行通信, A 有自己的加密密鑰和解密密鑰,同樣的 B 也有。

那怎麼解決密鑰傳輸的問題呢? 答案就是將 加密密鑰直接公佈出去

理解一下:

在通信的時候,A 把自己的加密密鑰給 B,B 把自己的密鑰給 A。

A 給 B 發送一個消息,然後通過 加密密鑰B 進行加密,然後發送給 B。B 接收到密文後就可以使用本地的解密密鑰 B 進行解密。但是:如果在發送的過程中被 C 截獲了加密密鑰和密文,那麼他能解密嗎? 顯然是不能的,因爲加密和解密的密鑰不是同一個,所以就算被截獲也無法解密

  • 在上面的問題中:

    加密密鑰對應着:公鑰

    解密密鑰對應着:私鑰

    其中公鑰是可以任意公佈的,但是私鑰不能對任何人公佈且不能進行傳輸。

  • 延時用途

    公鑰能不能解私鑰?

    可以,首先通過 私鑰進行加密,得到密文,接着使用公鑰再次進行加密就可以得到原數據。這種方式叫做簽名驗證。

    爲什麼呢?

    既然先通過 公鑰加密後在通過私鑰加密就可以得到原數據。那同樣的道理,通過私鑰加密後在通過公鑰加密就可以拿到原數據。

  • 簽名與驗證

    由於私鑰和公鑰互相可解,因此非對稱加密還可以用作數字簽名技術

    簽名:使用私鑰對原數據進行加密算法(稱爲簽名)得到簽名數據

    驗證:使用公鑰對原數據進行加密算法(稱爲驗證)得到原數據

    例如:我對某個文件進行簽名後,得到簽名數據。別人拿着一個看不懂的文件是可以通過公鑰驗證成功的就說明這個文件是由我親自進行簽名的。因爲私鑰只有我知道,沒有人可以隨意的造出一個可以剛好被公鑰驗證後是原數據的數據。

  • 同時使用 加密和簽名

    還是上面的那個圖

    A 發送消息 到 B ,在這個過程中可以被 C 給攔截到,C 無法解密出原數據,但是 C 可以使用公鑰重新加密一段數據發送給 B。

    例如 C發送:給我借 3萬元。然後 B 收到後就使用私鑰進行解密,發現是借錢,然後就會把錢打過去。這就會導致 B 的錢被騙走。

    怎麼解決呢:使用 加密+簽名

    A 發送消息的時候使用對方的公鑰進行加密,然後使用自己的私鑰對消息進行簽名

    B 收到消息後,使用自己的私鑰解密拿到原數據,還需要使用對方的公鑰進行驗證即可

    這樣一來,即時 C 拿到數據,他可以通過公鑰進行加密,但是他沒辦法通過私鑰進行簽名,所以這個問題就得到了解決。

  • 經典算法:RSA , DSA

    RSA:可以用來加密解密,和簽名

    DSA:專門被設計用來簽名的。他的優勢就是速度比較快。

  • 優點:可以在不安全的網絡上傳輸

  • 缺點:計算複雜,因此性能上比對稱加密差的很多

密鑰和登陸密碼

  • 密鑰(Key)

    密鑰就是一個剛好契合密文的東西,通過這個密鑰剛好就可以對密文進行解密

    • 場景:用於加密和解密
    • 目的:保證數據被盜是不會被人讀懂內容
  • 登陸密碼(password)

    相當於就是一個通行口令,是一個身份驗證。

    • 場景:用於進入網站或登陸時的身份驗證
    • 目的:數據提供方對用戶的數據進行保護,保證 “你是你” 的時候才提供權限

Base64

​ 將二進制數據轉換成由64個字符組成的字符串,分別是 大小寫26個字母,一共是52,然後是0 到 9,接着是 + / ,一共是64字符

  • 什麼是二進制數據

    非文本數據就是二進制數據,例如圖片,音樂,電影等都是二進制數據。

  • 用途

    • 讓原數據具有字符串所具有的特性,如可以放在 URL 中傳輸,可以保持到文本文件,可以通過普通的聊天軟件進行文本傳輸
    • 把原本人眼可讀的字符串變成不可讀的字符串,降低偷窺風險
  • Base64 加密傳輸圖片,可以更安全和高效,真的嗎?

    • Base64 沒有任何的安全可言,可通過碼錶逆向的得到元數據
    • Base64 的高效是假的。通過 Base64進行轉換後的字符串會比原來的數據大,所以不會高效,相反他是低效的。
  • 變種:Base58

    他把 Base64 中的字符給去掉了4個 ,0,O,I,l,+,/ ,這6個去掉了,因爲這個容易混淆,+ / 去掉是因爲雙擊複製。

  • 變種:URL encoding

    將 URL 中的保留字符使用 % 進行編碼,並且將 + 和 / 換成了另外兩個字符

    例如:https://blog.csdn.net/哈哈哈

    上面這個網址,放在瀏覽器中回車,然後將複製出來粘貼到下面如下:

    https://blog.csdn.net/%E5%93%88%E5%93%88%E5%93%88

    因爲瀏覽器不支持顯示漢子,即時你看起來是漢子,實際上他都已經轉換過了,

    如果在流量器中輸入 中 國,注意中間有個空格,在瀏覽器中,會直接使用 + 代替,而且 / 也有獨特的作用,這正是 在爲什麼需要將 + / 換成別的字符的原因。

    目的:消除歧義,避免解析錯誤

壓縮與解壓縮

  • 壓縮:把數據換一種方式來存儲,以減小存儲空間

  • 解壓縮:把壓縮後的數據還原爲原來的形式,以便使用

  • 常見的壓縮算法:DEFLATE,JPEG,MP3

    • DEFLATE:將一大堆東西歸檔,在歸檔的同時還可以進行壓縮
    • JPEG:對圖片進行壓縮
    • MP3:對聲音進行壓縮
  • 壓縮屬於編碼嗎?

    • 編碼到底是什麼意思?

      編碼沒有任何官方定義。例如:將 A 轉爲 B,並且還可以轉回來,在這個轉換的過程中沒人任何信息的損失,且不會增加任何信息。這個就是編碼

    壓縮和解壓縮是完全符合這個特點的。所以壓縮也是屬於編碼的一種形式。

媒體數據的編解碼

什麼是圖片,音頻,視頻的編解碼

  • 圖片的編碼:把圖像數據協程 JPG,PNG等文件的編碼格式

    其實就是把數據轉爲對應的格式,例如一個白點用 ffffff 表示,一個圖片的寬高是 64*64,那麼就會有 64 * 64 個 ffffff,

    要對這個 64*64 的圖片進行編碼可以指定的格式如:

    YS: ffffff=64*64;

    通過上面這個格式可以很清楚的看到,並且進行解碼。

    當然上面只是一個簡單的例子,好的算法可不是這麼幹的,但是意思到了就行了

  • 圖片的解碼:把 JPG,PNG 等文件中的數據解析爲標準的圖像數據。

  • 音頻,視頻的編解碼:和上面的都差不多,有有損壓縮和無損壓縮等,無非就是音質不太好,當然圖片也是可以的,例如微信表情現在 1mb,你就需要對圖片進行壓縮了,使用好的算法壓縮後的圖片會變小,但是看起來還是和原圖差不多。

序列化

把對象(一般是在內存中的)轉換成字節序列的過程

java 序列化機制

  • 目的:讓內存中的東西可以被存儲和傳輸

  • 序列化是編碼嗎?

    嚴格來說不是編碼,編碼是將 A 格式 轉爲 B 格式,並且可以任意相互轉換,但是序列化是將內存中的對象序列化爲字節的過程。其實都差不多,就看你怎麼理解了。

Hash

​ 把任意數據轉換成指定大小(通常很小)的範圍的數據,他在主要作用是 摘要,數字指紋。比如說有 200 個人,通過 hash 對這 200 個人進行編號,如 001,002等,每個編號對應着一個人,這個編號就被稱作爲 hash值。

  • 經典算法:MD5,SHA1,SHA256 等。

    hash 是有算法的,他會根據算法算出對應的 hash 值。在算出 hash 值得同時也要保證碰撞率非常低,碰撞率指的就是 hash 值不相同。還有就是不容易被破解。

    學過 java 的應該都知道 hashcode,可以重新 hashcode 方法進行自定義的 hash 值計算,如:

    public int hashCode(String sources){
    	return sources.length()
    }
    //傳入 哈好很 得到的 hash值:3
    //傳入 哈哈	 得到的 hash 值:2
    

    通過上面這個簡單的算法就可以得到對應的 hash 值。

    如果保證 hash 值得碰撞率非常低,這就需要一些比較高深的算法了。

  • 實際用途

    • 數據完整性驗證

      例如:從網上下載一個文件,這個文件的作者提供了一個 5g 的文件和一個 hash 值。然後你從網上下載,下載完成後在計算這個文件的 hash 值,如果和作者提供的一樣,就說明文件沒有損壞,否則的話就說明文件可能被篡改或者是損壞了。

    • 快速查找:hashCode 和 HashMap

      HashMap 原理

      hashCode與equals的作用與區別

      學過 java 的肯定都知道,重寫 hashCode 後必須要重寫 equals。這是爲啥呢?

      HashMap的數據結構是數組+鏈表的形式,通過hashCode獲取對應的下標,然後在判斷是否需要保存數據。 在保存數據的時候是通過 key 來保存的,這個鍵必須是惟一的。在保存的時候,傳入 key ,然後看源碼就可以發現,他會計算 key 的 hash 值,然後就會判斷這個 hash 是否是惟一的,也就是 hash 是否碰撞,如果沒有,則就會以這個 hash 值爲key ,將值保存起來,如果 hash 不是惟一的,就說明發生了 hash 碰撞。接着就會通過 equals 判斷 key 的內容是否相等,如果不相等就保存進去,否則就不保存。

    • 隱私保護

      • 明文:有些網站保存用戶信息的時候使用的是明文,就是 賬號密碼直接保存,在數據庫中是可見的,如果數據庫發送泄漏,那麼別人就可以直接拿到你的賬號密碼。這種明文存儲的壞處。

      • 不明文:什麼是不明文呢?就是對密碼進行 hash。登陸的時候只需要將密碼進行 hash 比較相同後說明真確,否則則不行。如果數據庫泄露,他拿到的也是一些 hash 值,並沒有用處,所以說是安全的。

      • 加鹽

        因爲 hash ,md5 不可逆,拿到 hash 之後,無法逆向的算出原密碼。但是那些非常閒的人就會將常用的密碼進行hash,然後在比較 hash 值是否相等。

        正應爲上面的這個原因,所以每個網站都有自己的鹽,在保存密碼的時候對 密碼和鹽進行 hash 值的計算,然後將對應的結果保存。這樣一來就算拿到 hash 值,也不可能比較出原密碼了。因爲 hash 值是進過加鹽的。

        所以每個網站的鹽必須要嚴格的保護,不能泄露。

    • Hash 是編碼嗎

      不是,Hash 是不可逆的。他只是抽取對象的特徵然後生成的一個 hash值。

    • Hash 是加密碼? MD5 是加密?

      其實都不是,加密指的是可逆的,加密後的數據進過計算後可以還原。但是 hash 和 MD5 都不不符合這個條件,你可以稱他們爲 “不可逆的轉換”

    • Hash 和 非對稱加密

      在 非對稱加密中進行簽名的時候,需要使用私鑰對原數據進行簽名,然後得到簽名文件。但是如果這個文件非常大,那麼這個簽名文件也會非常大,就會造成非常大的浪費。

      因此將 hash 算法放在了簽名中,流程如下:

      使用 hash 算法對原數據進行特徵的提取拿到 hash 值。然後通過私鑰對 hash 值進行加密(用私鑰加密叫做簽名),得到簽名後的值。

      驗證的時候:使用公鑰進行驗證,然後拿到 hash 值,然後在計算一下原數據的 hash 值,如果相同就說明成功,否則文件就被篡改了。

      使用這種方式,在發送消息的時候不管原數據多大,簽名數據都會非常小。

字符集

一個由整數向現實世界中的文字符號的 Map

  • 分支

    • ASCLL:128個字符,1字節

    • ISO-8859:對 ASCLL 進行擴充,1 字節

    • Unicode:13 萬個字符,多字節

      • UTF-8:Unicode 編碼分支
      • UTF-16:Unicode 編碼分支
    • GBK/GB2312/GB18030

原數據的 hash 值,如果相同就說明成功,否則文件就被篡改了。

  使用這種方式,在發送消息的時候不管原數據多大,簽名數據都會非常小。

字符集

一個由整數向現實世界中的文字符號的 Map

  • 分支

    • ASCLL:128個字符,1字節

    • ISO-8859:對 ASCLL 進行擴充,1 字節

    • Unicode:13 萬個字符,多字節

      • UTF-8:Unicode 編碼分支
      • UTF-16:Unicode 編碼分支
    • GBK/GB2312/GB18030

      中國自研標準,多字節,字符集+編碼

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章