主流的對稱密碼類型就是：DES、AES....，下面介紹一些其他類型。

可搜索加密

需求背景：
現在隱私泄露問題備受關注，大家都希望自己的信息以密文的形式上云，而不是以明文的形式上云。
但是這就會有個問題，如果需要對加密數據進行搜索，那怎么辦？ 總不能把云上所有的加密數據都下載下來，然后對其一一解密，再進行搜索吧。如果真是這樣，效率顯然會很低。因此，可搜索加密技術應運而生。

什么是可搜索加密技術？
可搜索加密技術是搜索技術和加密技術的結合。可搜索加密能夠實現將用戶的數據進行特殊的加密后上傳到云服務器上, 并且可以實現根據關鍵字進行檢索的功能, 有些可搜索加密方案更能實現范圍查詢或布爾查詢等高級檢索功能。在方便用戶使用的過程中, 也保護了文件的隱私安全。

分類：
可搜索加密技術一般分為：

• 對稱可搜索加密(Searchable Symmetric Encryption, SSE)

• 非對稱可搜索加密(Asymmetric Searchable Encryption, ASE)，非對稱可搜索加密目前一般又稱為公鑰可搜索加密(Public Key Encryption With Searching, PEKS)。（簡單的提起，下文不做介紹）

兩者有不同的應用場景和構造方式，對稱可搜索加密一般考慮單用戶使用的情況, 相當于建立個人加密云盤, 依賴對稱加密算法進行方案構造。

公鑰可搜索加密一般考慮多用戶使用的場景例如郵件系統或者多人文件共享系統, 主要依賴公鑰加密算法進行構造。

步驟：
對稱可搜索加密過程簡化為歸為以下 4 個步驟:

• 步驟 1. 建立和密鑰生成過程: 用戶對文件集合進行某種特殊加密后上傳至服務器并生成密鑰和加密數據庫;
• 步驟 2. 陷門生成過程: 用戶根據密鑰和將要檢索的內容生成特定陷門, 分為生成檢索陷門和生成更新陷門, 并都上傳給服務器;
• 步驟 3. 檢索過程: 用戶提交陷門, 由服務器根據陷門對加密數據庫進行安全搜索和返回結果, 用戶收到密文后解密得到最終結果;
• 步驟 4. 更新過程: 對于支持動態更新的可搜索加密, 可以通過將加密文件和更新陷門上傳到服務器進行文件添加或刪除操作, 注意添加操作和刪除操作是區分開來的。

陷門（Trapdoor） 是一種特殊的數學構造，它允許在特定條件下輕松計算某個函數，但在沒有特定信息（即“陷門”）的情況下，計算該函數的逆過程會非常困難。陷門是許多現代加密算法的核心組成部分。

實際案例：
假設你在使用一個加密云存儲服務：

1. 上傳文件：

   • 文件1 包含關鍵詞“合同”。
   • 文件2 包含關鍵詞“合同”和“發票”。
   • 你生成加密索引：
     \( \begin{cases} H(K, \text{“合同”}) = \text{a1b2c3d4} \rightarrow [\text{文件1}, \text{文件2}] \\ H(K, \text{“發票”}) = \text{e5f6g7h8} \rightarrow [\text{文件2}] \end{cases} \)
   • 上傳加密文件和加密索引到服務器。

2. 搜索文件：

   • 你想搜索包含“合同”的文件，生成陷門 $ \ T = H(K, \text{“合同”}) = \text{a1b2c3d4} $。
   • 服務器用 $\ T $ 匹配加密索引，找到 a1b2c3d4 對應的文件列表 [文件1, 文件2]。
   • 服務器返回加密的文件1和文件2。

3. 解密文件：

   • 你下載加密文件（文件1和文件2），用密鑰 $\ K \ $ 解密查看內容。

保留格式加密

定義：
保留格式加密是一種現代加密技術，確保加密后的密文與原始明文格式完全一致（如長度、字符類型）。例如，加密信用卡號后，密文仍是16位數字。

保留格式加密（FPE）和古代的凱撒加密有點類似，但FPE是一種現代加密技術，其核心目標是加密后的密文與明文格式完全一致（如長度、字符類型）。FPE的加密過程比凱撒加密復雜得多，通常基于分組加密算法（如AES）和特定的模式（如FF1、FF3）。

好處：
可以確保加密數據安全的同時仍然可用并與處理它的系統兼容。因此，它在原始數據的格式和長度至關重要的場景中非常有用，例如數據庫、應用程序或具有特定數據輸入要求的系統。

核心原理
FPE的加密過程比凱撒加密復雜得多，通常基于分組加密算法（如AES）和特定的模式（如FF1、FF3）。

• 格式約束：加密算法根據明文格式（如數字、字母、日期）動態調整加密過程。
• 分塊加密：將數據分塊后，用特定模式（如FF1、FF3模式）加密，確保輸出格式一致。
• 密鑰派生：通過密鑰和格式規則生成中間密鑰，控制加密結果。

常見標準

• NIST標準：FF1（AES-based）、FF3-1（改進版FF3），支持數字、字母等格式。
  例子：
  • 明文：4111 1111 1111 1111（信用卡號）
  • 密文：3569 2354 8234 5678（格式相同，但數值隨機化）。

應用場景

• 支付卡數據加密（PCI-DSS合規要求）。
  例子：4111 1111 1111 1111 → 3569 2354 8234 5678。

• 數據庫字段加密（如加密身份證號，保持數字格式）。
  例子：310105199001011234 → 510203198912345678。

• 日志脫敏（加密日志中的敏感信息，不影響日志分析工具）。
  例子：UserID: 12345 → UserID: 67890。

局限性

• 安全性弱于傳統加密（因格式限制，密鑰空間可能縮小）。
• 實現復雜度高，需嚴格遵循標準（如FF1/FF3）。

Reference

http://www.rzrgm.cn/shirleyya/p/15024342.html
可搜索加密技術 - 學習筆記（一）