1. 資料庫當前面臨的威脅模型
2. 加密策略描述，當前PostgreSQL社群目前的設計狀態以及其他資料庫TDE方案對比
3. 未來的資料安全暢想

那什麼是透明資料加密？

透明資料加密，從字面上來說，可以分為三部分，資料，加密，透明。 資料，這裡不用過多解釋，使用者需要保護的明文資料。 加密，相信大家也清楚，資訊保安一直伴隨著世界的發展，加密是資訊保安的一種重要手段，常用加密方法目前可以分為流密碼加密、分組加密以及公鑰加密3種。 透明，指的是使用者無感知，這是對加密行為的描述。

透明加密技術是近年來針對企業檔案保密需求應運而生的一種檔案加密技術。是指對使用者來說是無感知的。當使用者在開啟或編輯指定檔案時，系統將自動對未加密的檔案進行加密，對已加密的檔案自動解密。檔案在硬碟上是密文，在記憶體中是明文。一旦離開使用環境，由於應用程式無法得到自動解密的服務而無法開啟，從而起來保護檔案內容的效果。 --摘自《百度百科》

一般涉及到加密碼學相關話題時，我們首先要清楚面對的安全威脅是什麼？

當前資料庫資料面臨的威脅模型

1. 不恰當的許可權 很多應用或者軟體在使用過程中，往往因為使用的便利，將不必要的許可權賦予使用者；其次，未及時清理無效的使用者（比如，離職員工），同樣會造成資訊的洩露。 大多數應用軟體不會對於DBA和開發人員進行過多的限制，這同樣有資料丟失的風險。 許可權賦予策略、三權分立或者資料庫審計都是有效防範此類威脅的重要手段。

2. SQL注入攻擊 SQL注入攻擊一直是資料庫面臨的重大風險之一。隨著B/S模式應用開發的發展，使用這種模式編寫應用程式的程式設計師也越來越多。但是由於程式設計師的水平及經驗也參差不齊，相當大一部分程式設計師在編寫程式碼的時候，沒有對使用者輸入資料的合法性進行判斷，使應用程式存在安全隱患。使用者可以提交一段資料庫查詢程式碼，根據程式返回的結果，獲得某些他想得知的資料。 合理的軟體架構設計以及合法的SQL審計，是防範此類威脅的有效方法。

3. 惡意攻擊 攻擊者可以通過網路竊聽、木馬攻擊等方式影響資料庫，造成資料丟失風險。很多廠商往往會因為效能或者資源等原因，沒有開啟網路傳輸加密，從而造成資料竊聽風險。 其次，惡意攻擊者可以通過木馬病毒等措施，感染合法使用者裝置，從而竊取資料，造成資料丟失。 提高安全措施，比如開啟防火牆，開啟網路傳輸加密等，其次加強資料庫審計可以方法此類威脅。

4. 弱審計跟蹤 由於資源的消耗、效能的下降，很多廠商關閉或者開啟較少功能的審計跟蹤，這會導致惡意的管理員對於資料的非法侵入。 其次，由於審計之後的限制操作比較難以實現，比如對於DBA和非法侵入就難以區分，從而導致審計之後的操作難以防禦攻擊。 網路裝置審計是目前最有效的審計方案。

5. 不安全的儲存介質 儲存介質儲存竊取的風險，其次備份儲存儲存安全設定較低的因素，這都會造成資料丟失。 提高物理介質的保護，加密使用者資料，加強所有資料儲存的安全設定能夠防範此類威脅。

6. 不安全的第三方 隨著雲時代以及5G的到來，更多的廠商將資料儲存到雲端。這其實存在第三方信任問題。如果第三方存在惡意管理員，非法竊取或讀取敏感資料；或者提供存在安全隱患的伺服器，這都會造成資料丟失。 選擇可信任的第三方，加密使用者資料，可以避免不安全的第三方威脅。

7. 資料庫漏洞或者錯誤的配置 隨著現代資料庫軟體的功能增多，複雜的程式很可能會存在安全漏洞，而且很多廠商為了保證系統的穩定性不願意進行版本升級，同樣資料面臨很大的洩露風險。 其次，安全設定不足也存在很高的風險。這裡的安全配置不僅僅指的是資料庫層面，作業系統層面也需要加強安全配置。 定期修復資料庫漏洞，加強安全配置。

8. 有限的安全專業知識和教育 據統計，大約有30%的資料洩露事件是由人為疏漏造成的，所以安全教育同樣需要加強。 定期進行安全專業知識講座，提高安全防範意識。

綜上所述，目前資料加密能夠應對的威脅有有不安全的儲存介質，不安全的第三方。 而我們知道資料庫不僅需要安全因素的考量，同時需要兼顧效能、穩定、易用的因素。那麼如何設計資料加密？

加密等級

首先我們回顧一下PostgreSQL整體架構：

通過整體架構來看，我們可以將加密分為6個等級。 從上圖可以看到，客戶端和服務端進行互動，使用者資料自客戶端起，由服務端接收，並寫入到服務端快取中，再刷入到磁碟內。 而PostgreSQL儲存物理結構為：叢集-->表空間-->資料庫-->關係物件。 由此我們可以將資料庫分為6個層級進行加密，分別是，客戶端加密，服務端加密，集簇級加密，表空間級加密，資料庫級加密以及表級或物件級加密。 下面對這6個層級進行分別闡述：

1. 客戶端加密，由使用者生成金鑰，對欄位進行加密；
   1. 優點：在某種程度上能夠防範DBA以及開發人員；加密粒度小，加密資料量可控。現有的加密外掛pgcrypto可以客戶端的資料加密功能。
   2. 缺點：使用成本較高，需要調整現有應用系統，對資料插入語句進行修改；其次由於從資料生成開始加密，等於是快取級加密，效能較差，索引無法使用。
2. 服務端加密，建立加密型別，對欄位進行加密；
   1. 優點：使用成本相對於客戶端加密較低，僅需要對資料庫進行調整，無需修改應用程式，加密粒度小，加密資料量可控。
   2. 缺點，同樣是快取級加密，效能較差，索引無法使用。
3. 集簇級加密，對整個集簇進行加密，初始化時確定集簇是否加密；
   1. 優點：架構簡單，使用成本低，作業系統快取級加密（資料快取刷入、讀取磁碟時加解密），效能相對較好；
   2. 缺點，加密細粒度大，所有集簇內物件都會加密，會造成效能下降。
4. 表空間級加密，對某一個表空間設定加密屬性，所有在加密表空間內都預設加密；
   1. 優點：架構簡單，使用成本低，作業系統快取級加密，效能相對較好，加密細粒度降低，能夠更好的控制加密資料量，有利於資料加密效率；
   2. 缺點：表空間在PostgreSQL的概念不夠明確，使用者容易誤解，其次在備份管理等方面使用成本較高。
5. 資料庫級加密，指定某個庫為加密庫，所有在加密庫中的物件預設加密；
   1. 優點：架構簡單，使用成本低，作業系統快取級加密，加密細粒度降低，資料加密效率高；
   2. 缺點：加密細粒度相對較大。
6. 表級加密或者檔案級加密，指定某個物件加密；
   1. 優點：架構簡單，使用成本低，作業系統快取級加密，加密細粒度進一步降低，資料加密效率高；
   2. 缺點：金鑰管理成本較大，開發複雜度較高。其次當需要加密的物件較多時，使用成本較高。

這裡解釋以下為什麼快取級加密無法建立索引的原因： 建立索引的目的是提高資料建索效率，而加密的原因是保護敏感資料。

• 那麼如果我們在快取級加密，如果建立索引，這裡也需要分為兩種情況，基於明文建索引或基於密文建索引。
  • 基於明文建索引則需要對明文進行解密，建立索引，後對索引加密，但這樣加解密次數過多，會引起效能下降，其次索引本身的順序也會造成一定的資訊洩漏。
  • 基於密文建索引則索引無法有效對資料排序，也就難以起到快速減速的能力。
• 那如果不對索引加密，則會對資料安全產生影響。

當然如果加密後不使用索引則不會有任何影響。

上面提到了快取級和檔案系統級加密接下來從儲存架構上來看：

由上圖可知，我們可以分為三個等級，資料庫快取級，作業系統快取級以及檔案系統級：

資料庫快取級加密：上述的等級1、2都是資料寫入快取時已經加密，快取級加密，資料檢索時解密，效能最差； 作業系統快取級：等級3、4、5、6都是在PostgreSQL資料刷寫磁碟是加密，資料載入時解密，效能相對較好； 檔案系統級：資料庫自身無法實現，需要使用檔案系統加密，資料庫不可控。

那對於資料庫來說應該如何選擇？ 雖然加密是一種很好的資料安全保護手段，但是如何加入到資料庫中還需要進行整體性考慮。 在對資料庫進行加強時，我們需要考慮

• 開發成本
• 安全性
• 效能
• 易用性

社群經過多次討論，目前由於設計難易度以及開發成本的角度，選擇了集簇級加密作為TDE的第一個方案。

我們都知道，常用加密目前主要有流式加密、分組加密、公鑰加密三種。 在使用加密演算法的時候，應注意：

• 加密方法由兩部分構成，金鑰以及加密演算法。通常我們建議使用國際公開、認證的加密演算法。
• 金鑰的保護等同於明文的保護。

所以如何進行加密我們將會分為兩部分講述：加密演算法的選擇以及金鑰的管理。

加密演算法選擇

首先分析一下三種加密方式：

1. 流式加密的特性是，金鑰長度與明文資料長度一致，而這在資料庫中是難以實現的，所以在這不考慮。
2. 公鑰加密是最大的優勢在於分為公私金鑰，公鑰是可以公開的，這就降低了金鑰管理的問題，但是其加密效能太差，分組加密演算法是公鑰加密的幾百倍，所以在此也不進行考慮。
3. 分組加密是目前主流的加密演算法，效能最優，應用最廣。

而當前國際公認的分組加密演算法是AES。 下面我們簡單介紹一下AES。 分組加密演算法，首先需要分組，AES的加密長度為128bits，也就是說16 bytes。 擁有3種金鑰長度，128，192以及256。 AES擁有5種加密模式：

ECB mode: Electronic Code Book mode，電子密碼本模式 CBC mode: Cipher Block Chaining mode，密碼分組連結串列模式 CFB mode: Cipher FeedBack mode，密文反饋模式 OFB mode: Output FeedBack mode，輸出反饋模式 CTR mode: Counter mode，計數器模式

5種模式的加密流程

ECB mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 使用相同的金鑰進行加密明文； iii. 得到密文； iv. 逆向則解密。

CBC mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 初始化16位元組長度的IV（Initialization Vector，向量）； iii. 使用IV和明文進行異或； iv. 使用相同的金鑰加密步驟iii的結果； v. 得到密文； vi. 使用密文作為一下次加密時與明文進行異或的資料； vii. 逆向則解密。

CFB mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 初始化16位元組長度的IV； iii. 使用相同的金鑰進行加密IV； iv. 使用加密後的IV和明文進行異或； v. 得到密文； vi. 使用金鑰加密密文，與一下次的明文進行異或，重複iv，v，vi； vii. 逆向則解密。

OFB mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 初始化16位元組長度的IV； iii. 使用金鑰加密IV； iv. 使用加密後的IV對明文異或； v. 在此使用金鑰加密步驟iii結果，重複步驟iv和v，直至完成整個明文加密； vi. 逆向則解密。

CTR mode

a. 加密：

b. 解密：

c. 過程： i. 將明文進行分組，以16位元組為一組； ii. 初始化計數器，要求所有計數為唯一值； iii. 使用金鑰加密計數； iv. 使用加密後的計數和明文異或； v. 得到密文； vi. 重複步驟iii，iv，v； vii. 逆向則解密。

5種模式的異同

上述闡述了，5種mode的加密過程，由此不同的加密過程，則產生異同點：

5種模式的加解密效率

加密：

解密：

注：以上資料僅是單程序下的對比。

資料庫中如何選擇加密模式

開發成本：使用openssl自帶的加密演算法，加密演算法開發成本低；其中除ECB外都需要額外的使用向量或計數器，開發成本相當；由於CBC和ECB需要進行填充資料，考慮到WAL流複製過程，不推薦使用。最優選擇為CFB，OFB和CTR。 安全性：ECB不予考慮，其他皆可。 效能：由於是在刷寫磁碟時進行加解密，那麼考慮到讀取和寫入的並行要求，以及加密演算法的效能，CTR mode是最優選擇。 易用性：在此不需要考慮。

以上，從各個層面來說，CTR都是最優的加密mode，社群同樣選擇了CTR mode作為加密模式。

資料庫中如何使用CTR mode

要新增CTR mode到資料庫，需要了解CTR的加密過程。 從上面的加解密流程可以知道，CTR加解密時需要4部分共同協作，明/密文，演算法，計數器，金鑰。

• 演算法本身是呼叫openssl的CTR mode，所以這裡無需開發，只需要熟讀openssl的文件即可。
• 明/密文，根據加密等級的介紹，資料庫是將快取刷入磁碟時進行加密的，也就是說將會對page進行加解密，其大小為8192 bytes，正好是加密塊的整數倍；其次在考慮流複製的特殊性，我們也會對recode進行加解密。
• 計數器，根據NIST的加密演算法說明，我們可以知道，這裡的計數器不要求強隨機，只要是保證不重複即可。其次，計數同樣需要儲存在資料庫中。因此考慮使用page頁上的LSN來作為計數器的一部分，（這裡要說明的是，LSN是存在重複的可能性。社群目前有人提供一個新的補丁來防止LSN重複的可能），其次使用檔名以及也的順序作為其中的一部分。以此來保證其唯一性。
• 金鑰，金鑰的保護等於密文的保護。所以金鑰如何生成、管理是非常重要的。將由下面這個章節進行說明。

金鑰管理

金鑰管理由四部分構成：金鑰生成、金鑰交換、金鑰儲存以及金鑰輪轉。

金鑰生成

上面的章節介紹了我們將會選擇對稱分組加密方法進行加解密，那麼我們的金鑰即是對稱金鑰。而對稱密碼生成方法有：

• 隨機數作為金鑰
• 基於口令的金鑰生成
• HKDF（HMAC-based Extrac-and-Expand Key Derivation Function）

1. 隨機數作為金鑰：這很用以理解，使用強隨機數生成器，生成金鑰。

2. 基於口令的金鑰生成：根據使用者口令生成金鑰並使用它進行加解密的方法。具體方法如下：

   1. 使用者輸入口令；
   2. 系統生成隨機數，與使用者口令進行hash計算，得到金鑰加密金鑰；
   3. 儲存金鑰加密金鑰至安全處；
   4. 系統生成隨機數作為資料加密金鑰；
   5. 金鑰加密金鑰對資料金鑰進行加密，同樣也儲存到安全處；
   6. 使用資料加密金鑰對資料加解密。

3. HKDF：金鑰派生函式(KDF)是密碼系統的基本組成部分。它的目標是獲取一些初始的金鑰材料，並從中派生出一個或多個安全強度很大的金鑰。

   1. 提取，使用強隨機數和輸入的資訊使用hmac方法進行hash運算；
   2. 擴充套件，通過多次hash計算，對上面結果進行擴充套件，擴充套件到我們需要的長度。

金鑰儲存

金鑰的生成無論是隨機數的還是基於口令的，都有一部分是目前難以記憶的，所以這就需要儲存金鑰了（也可能是salt）。 金鑰不能與資料儲存在同一位置，否則等於是鑰匙掛在門上，沒有任何意義。 我們一般需要將金鑰儲存在檔案內，放到保險櫃等安全的儲存位置或者安全的金鑰分配中心。 當時當金鑰數量達到一定數量時，我們就需要另一種金鑰，KEK（Key encryption key，金鑰加密金鑰）。 這是由於金鑰如果不進行加密，竊取後，盜取者很容易使用金鑰對資料解密了。同樣，管理多個金鑰難度遠遠大於單個金鑰。 所以可以考慮使用KEK來儲存金鑰的一種方式，當然KEK也需要儲存在安全的位置。

金鑰交換

金鑰交換目前有4種：事先共享金鑰，使用金鑰分配中心，使用公鑰密碼以及Diffie-Hellman金鑰交換方法。

下面簡單描述一下4種方法： 事先共享密碼： 雙方加密前通過安全途徑交換金鑰，但是在資料庫中，雙方為服務端和磁碟，即金鑰和磁碟在同一區域，不安全，所以資料庫不會考慮這種方式。

使用公鑰密碼： 由於我們這裡使用對稱加密體系，所以不考慮公鑰。但是這可以作為金鑰交換的一部分使用。

使用金鑰分配中心： 將金鑰儲存到可信任的第三方，使用時通過第三方獲取金鑰。在需要使用金鑰時，向第三方通訊，生成會話金鑰，使用會話金鑰加密金鑰進行傳送金鑰。 這裡的會發金鑰可以使用公鑰加密體系。

Diffie-Hellman金鑰交換： Diffie-Hellman是1976年由Whitfield Diffie和Martin Hellman共同發明的一種演算法。該演算法可以通過交換可以公開的資訊就能夠生成共享的祕密數字，從而達到共享金鑰的目的，其過程如下圖所示：

1. DB server向Key server（以下簡稱D和K）傳送兩個質數P，G；
2. D生成一個隨機數A；
3. K生成一個隨機數B；
4. D將GA mod P 傳送給K；
5. K將GB mod P 傳送給D；
6. D使用K發過來的數B', 計算B’mod P，這就是資料加密金鑰；
7. K使用D發過來的數A'，計算A' mod P，這個和D計算得到的加密金鑰是相等的；

當然再加入資料庫時，同樣需要使用安全第三方作為資訊交換，但這減少了金鑰被竊聽的可能性。

金鑰輪轉

金鑰輪轉，分為金鑰更新和作廢兩部分。 金鑰更新，更新可以提高金鑰暴力破解的難度，其次即便是過去的金鑰被破解也無法獲取當前的資料。 金鑰作廢，在更新後要及時對金鑰進行作廢，這裡的作廢不僅僅指的是刪除，而是要達到無法還原金鑰的目的。

TDE的金鑰管理方法

以上金鑰管理方法沒有明確不推薦的情況下，都是可以使用的。 筆者再和社群溝通的過程中推薦的是，基於口令的金鑰生成，使用KEK儲存金鑰，Diffie-Hellman金鑰交換的方案。

當前社群經過多輪討論後，目前由兩種方案2層金鑰管理以及3層金鑰管理：. 相面對其進行介紹：

2層金鑰管理：

2層金鑰管理使用的是，基於口令的金鑰生成，使用KEK儲存金鑰以及使用金鑰分配中心3者的結合，架構體系如下圖：

這和之前講到的基於口令的密碼很相似，不過資料加密金鑰將會儲存到資料庫伺服器，這有別於基於口令的密碼儲存到外部伺服器。

3層金鑰管理：

這裡使用的是，基於口令的金鑰生成，HKDF，使用KEK儲存金鑰以及使用金鑰分配中心4者的結合，架構體系如下圖：

1. 使用者輸入口令；
2. 系統生成隨機數，與使用者口令進行hash計算，得到金鑰加密金鑰；
3. 隨機數儲存至安全處；
4. 系統生成隨機數作為MDEK（master data encryption key），儲存至安全處；
5. 使用MDEK和加密檔案資訊得到資料加密金鑰；
6. 使用資料加密金鑰對資料進行加解密。

目前金鑰管理還有一定爭議，我個人比較贊同第二種方式，為後期更小加密細粒度做準備。

其他資料庫TDE方案對比

做任何事情都不是閉門造車，現階段，很多資料庫已經支援了TDE，我們對此進行對比，以此來確定最優的方案：

1. Oracle
   • 加密等級：Tablespace-level，Column-level
   • 加密演算法：AES，3DES
   • 金鑰管理：主金鑰和資料加密金鑰
2. SQL Servel
   • 加密等級：Database-level
   • 加密演算法：AES，3DES
   • 金鑰管理：系統金鑰，主金鑰，系統證書，資料加密金鑰
3. DB2
   • 加密等級：Database-level
   • 加密演算法：AES，3DES
   • 金鑰管理：主金鑰和資料加密金鑰
4. MySQL
   • 加密等級：Tablespace-level，Column-level
   • 加密演算法：AES，3DES
   • 金鑰管理：OASIS Key Management Interoperability Protocol (KMIP) TC

未來的資料安全暢想

現在5G的來臨，雲時代的來臨，我想未來的IT架構，更多的都是基於雲的設計。更多的資料儲存在雲上，那麼雲廠商如果對使用者資料竊取、分析，那都會嚴重侵犯我們的隱私。 之前在威脅模型中也說到的惡意DBA和開發人員，他們往往具有較高的資料庫許可權，哪怕沒有許可權，他們如果有讀取快取的方法，那麼資料同樣會洩露。 那麼如何保護我們的資料呢？

同態加密

同態加密是基於數學難題的計算複雜性理論的密碼學技術。對經過同態加密的資料進行處理得到一個輸出，將這一輸出進行解密，其結果與用同一方法處理未加密的原始資料得到的輸出結果是一樣的。 --摘自《百度百科》

同態加密（Homomorphic Encryption）是很久以前密碼學界就提出來的一個Open Problem。早在1978年，Ron Rivest, Leonard Adleman, 以及Michael L. Dertouzos就以銀行為應用背景提出了這個概念。

一般的加密方案關注的都是資料儲存安全。即，我要給其他人發個加密的東西，或者要在計算機或者其他伺服器上存一個東西，我要對資料進行加密後在傳送或者儲存。沒有金鑰的使用者，不可能從加密結果中得到有關原始資料的任何資訊。只有擁有金鑰的使用者才能夠正確解密，得到原始的內容。我們注意到，這個過程中使用者是不能對加密結果做任何操作的，只能進行儲存、傳輸。對加密結果做任何操作，都將會導致錯誤的解密，甚至解密失敗。同態加密方案最有趣的地方在於，其關注的是資料處理安全。同態加密提供了一種對加密資料進行處理的功能。也就是說，其他人可以對加密資料進行處理，但是處理過程不會洩露任何原始內容。同時，擁有金鑰的使用者對處理過的資料進行解密後，得到的正好是處理後的結果。

如果不是很理解他的概念，那麼我們可以看下圖：

同態加密你可以想象，DBA和開發人員或者惡意的雲管理員，他們就像是操作工人（攻擊者），必須帶著手套在加鎖的盒子裡（加密演算法）處理金子，沒有鑰匙（金鑰）打不開，如此，他們是無法竊取金子（資料）的。

那麼未來如何使用同態加密呢？

Alice通過Cloud，以Homomorphic Encryption（以下簡稱HE）處理資料的整個處理過程大致是這樣的： Alice對資料進行加密。並把加密後的資料傳送給Cloud； Alice向Cloud提交資料的處理方法，這裡用函式f來表示； Cloud在函式f下對資料進行處理，並且將處理後的結果傳送給Alice； Alice對資料進行解密，得到結果。

那麼為什麼現在還沒有大規模應用呢？根據IBM團隊的研究，直到2016年，該技術都還存在效能瓶頸，巨大的效能開銷讓人無奈至極。 同態加密的發明者克雷格•金特里(Craig Gentry)帶領IBM的研究團隊進行了一系列同態加密嘗試。最初的時候，同態加密的資料處理速度比明文操作慢“100萬億倍”，後來在16核伺服器上執行，速度就提升了200萬倍，但還是比明文操作慢很多。因此，IBM繼續改進HElib，其釋出在GitHub上的最新版就重新實現了同態線性變換，效能得到極大提升，速度加快了15-75倍。國際密碼學研究協會的一篇論文中，IBM密碼研究團隊的謝•哈勒維(Shai Halevi)和紐約大學庫朗數學研究所教授維克多•舒普（Victor Shoup，同時供職IBM蘇黎世研究實驗室）闡述了速度提升的方法。

所以當前同態加密的效能無法滿足正常需要，如果商用到資料庫層面，我認為還需要密碼學家的進一步研究。請大家期待吧。

寫在最後

以上所有方法都是軟體層面的操作，目前關於資料加密其實湧現了很多硬體解決方案，比如FPGA卡加解密，以提高其效能；還有Intel的基於可信執行環境技術（TEE，Trusted Execution Environment）的可信計算等等。 加密也僅僅是資料庫安全的一小部分，更多的內容需要大家的共同努力，也希望在未來能夠看到更多的人從事到資料庫安全領域當中。

參考文章

1. http://raghavt.blogspot.ca/2011/04/postgresql-90-architecture.html
2. Computer Security -- NIST
3. RFC 5869 - HMAC-based Extrac-and-Expand Key Derivation Function.pdf
4. https://www.zhihu.com/question/27645858/answer/37598506
5. https://zhuanlan.zhihu.com/p/82191749
6. https://www.postgresql.org/message-id/flat/CAD21AoAB5%2BF0RAb5gHNV74CXrBYfQrvTPGx86MrEfVM%3Dx4iPbQ%40mail.gmail.com#321a08844300a49c89590cbf12ccb12a
7. https://wiki.postgresql.org/wiki/Transparent_Data_Encryption
8. https://www.slideshare.net/masahikosawada98/transparent-data-encryption-in-