密碼學與加密技術基礎概念

1. 密碼學基本定義

在資訊安全領域，密碼學的主要目標，是保護資料在傳輸或儲存時的安全性。常見目標包含：

• 機密性 (Confidentiality)：避免未授權者讀取資料內容。
• 完整性 (Integrity)：確認資料沒有被竄改。
• 身分驗證 (Authentication)：確認通訊對象或資料來源的真實性。
• 不可否認性 (Non-repudiation)：讓發送者事後難以否認曾經送出某筆資料或簽署某份文件。

一個加密系統通常包含以下幾個元素：

• 明文 (Plaintext)：尚未加密、可直接閱讀的原始資料或訊息。
• 密文 (Ciphertext)：經過加密演算法處理後，無法直接閱讀的資料。
• 金鑰 (Key)：控制加解密或簽章運算的祕密參數。
• 演算法 (Algorithm)：執行加密、解密、雜湊、簽章或驗證的數學程序。

現代密碼學的重要原則是 柯克霍夫原則 (Kerckhoffs’s Principle)：

一個密碼系統的安全性，應建立在金鑰的保密性上，而不是演算法本身的保密性上。

也就是說，現代主流加密演算法通常是公開的，並接受長期的學術與產業檢驗。

---

2. 對稱加密與非對稱加密

依據加解密過程中使用的金鑰關係，加密技術主要分為 對稱加密 與 非對稱加密。

---

2.1 對稱加密

對稱加密是指加密與解密使用同一把金鑰。

傳送端使用金鑰將明文加密成密文，接收端必須持有同一把金鑰，才能將密文解回明文。

特點

• 優點：速度快、運算成本低，適合加密大量資料，例如檔案、資料庫欄位、即時網路流量。
• 缺點：金鑰必須安全地交給接收端，否則金鑰一旦外洩，加密資料就可能被解開。

常見演算法

• AES (Advanced Encryption Standard)：目前最常見、也最推薦的新系統對稱加密標準。
• DES：因金鑰長度過短，已不具備足夠安全性，不建議使用。
• 3DES：曾用來延長 DES 的壽命，但已逐步淘汰，不建議新系統使用。

---

2.2 非對稱加密與公鑰密碼學

非對稱加密又稱為 公鑰密碼學，使用一組數學上相關聯的金鑰：

• 公鑰 (Public Key)：可以公開給任何人。
• 私鑰 (Private Key)：必須由持有人妥善保管，不能外洩。

在「公鑰加密」的使用情境中，任何人都可以用接收者公鑰加密資料，但只有持有對應私鑰的人可以解密。

特點

• 優點：降低對稱金鑰一開始安全交換的難度，也可用於身分驗證與數位簽章。
• 缺點：相較於 AES 這類對稱加密，非對稱密碼學的運算成本較高，因此通常不直接用來加密大量資料。

常見演算法

• RSA：基於大整數分解困難問題。
• ECC (Elliptic Curve Cryptography)：基於橢圓曲線離散對數問題，通常能以較短金鑰提供相近安全強度，是現代主流方向之一。

注意：數位簽章不是單純的「私鑰加密、公鑰解密」。比較精準的說法是「使用私鑰簽署，使用公鑰驗證」，詳見第 5 節。

---

3. 實務上的混合加密技術

實務上，系統通常不會只使用對稱加密或只使用非對稱加密，而是將兩者搭配使用，稱為 混合加密 (Hybrid Encryption)。

以現代 HTTPS / TLS 為例：

1. 握手與金鑰協商階段
   用戶端與伺服器會先進行 TLS 握手。伺服器透過數位憑證與數位簽章證明自己的身分，雙方再透過 ECDHE / DHE 等金鑰協商機制產生共享祕密，並由此衍生出後續通訊使用的對稱會話金鑰。

2. 資料傳輸階段
   安全通道建立後，後續 HTTP 訊息會使用對稱加密傳輸。這包含大多數 HTTP request / response 內容，例如 headers 與 body。

flowchart TD
    subgraph Handshake ["1. TLS 握手與金鑰協商階段"]
        Cert["驗證伺服器數位憑證"] --> KeyExchange["透過 ECDHE / DHE 進行金鑰協商"]
        KeyExchange --> SessionKey["雙方衍生出對稱會話金鑰"]
    end

    subgraph DataTransfer ["2. 資料傳輸階段"]
        Client["用戶端使用會話金鑰加密 HTTP 訊息"] <-->|安全且高效率的雙向傳輸| Server["伺服器使用會話金鑰加解密 HTTP 訊息"]
    end

這種設計同時取得：

• 非對稱密碼學的身分驗證與安全金鑰協商能力。
• 對稱加密的高效率資料傳輸能力。

---

4. 密碼學雜湊函數

雜湊函數不是加密。

加密通常可以解密回原文，但雜湊函數是將任意長度的輸入資料，轉換成固定長度的輸出值，且設計目標是難以從輸出反推出原始輸入。

密碼學雜湊函數通常需要具備以下特性：

特性	說明
單向性 (Preimage Resistance)	從輸入算出雜湊值很容易，但從雜湊值反推出原始輸入極困難。
第二原像抗性 (Second Preimage Resistance)	給定一筆輸入資料後，極難找到另一筆不同資料卻產生相同雜湊值。
抗碰撞性 (Collision Resistance)	極難找到任意兩筆不同資料，卻產生相同雜湊值。
雪崩效應 (Avalanche Effect)	輸入只要改變一點點，輸出就會出現大幅且不可預測的變化。

常見演算法

• SHA-256：目前常見於檔案完整性驗證、數位簽章、區塊鏈等場景。
• MD5 / SHA-1：已被證實存在碰撞風險，不適合安全用途；若使用，也應限於非安全性的快速校驗。

常見應用

1. 密碼儲存

資料庫不應儲存使用者密碼明文。基本概念是儲存密碼經過「加鹽雜湊」後的結果。

但實務上不建議直接使用 SHA-256 + salt 儲存密碼，因為 SHA-256 太快，攻擊者可以大量嘗試密碼。應使用專為密碼儲存設計、可調整計算成本或記憶體成本的演算法，例如：

• Argon2
• bcrypt
• scrypt
• PBKDF2

2. 檔案完整性驗證

下載大型軟體或映像檔時，官方通常會提供 SHA-256 值。使用者可以重新計算下載檔案的雜湊值，確認檔案是否完整、是否遭到竄改。

---

5. 數位簽章

數位簽章用來確認資料來源與資料完整性，常見用途包含軟體發布、憑證驗證、電子文件簽署、區塊鏈交易等。

數位簽章的核心概念是：

使用私鑰簽署 (Sign)，使用公鑰驗證 (Verify)。

它不是單純把訊息或摘要「用私鑰加密」。在 RSA-PSS、ECDSA、EdDSA 等現代簽章演算法中，簽章是一套獨立的數學運算流程。

flowchart TD
    subgraph Sign ["1. 傳送端：產生簽章"]
        Doc["原始文件"] --> HashA["計算訊息摘要"]
        HashA --> Signature["使用私鑰與簽章演算法產生數位簽章"]
    end

    subgraph Verify ["2. 接收端：驗證簽章"]
        RecDoc["收到文件"] --> HashB["重新計算訊息摘要"]
        RecSig["收到簽章"] --> VerifyAlgo["使用公鑰與驗證演算法檢查簽章"]
        HashB --> VerifyAlgo
        VerifyAlgo -->|有效| Valid["驗證成功：來源可信，內容未被竄改"]
        VerifyAlgo -->|無效| Invalid["驗證失敗：來源不明或內容已被改動"]
    end

    Doc -.->|傳輸| RecDoc
    Signature -.->|傳輸| RecSig

簽署階段

發送端先對文件計算雜湊值，再使用自己的私鑰與簽章演算法產生數位簽章，並將文件與簽章一起送出。

驗證階段

接收端使用發送端的公鑰與驗證演算法檢查簽章是否有效。如果驗證成功，通常代表：

1. 文件確實由持有對應私鑰的人簽署。
2. 文件在簽署後沒有被竄改。

注意：數位簽章只能證明「這個簽章對應到某把私鑰」。至於這把公鑰是否真的屬於某個人或某台伺服器，還需要依賴憑證、信任鏈或其他身分驗證機制。

---

相關概念延伸閱讀

• 網路通訊基礎概念與協定原理：了解 TLS/HTTPS 在網路通訊中的位置。
• 網頁基礎概念與運作原理：理解 HTTPS 如何保護網頁資料傳輸。