以抹除碼提升雲端儲存服務的安全性之研究

全文

(1)國立高雄大學資訊工程學系碩士論文. 以抹除碼提升雲端儲存服務的安全性之研究 Enhancing Security of Cloud Storage by Erasure Coding. 研究生：王派星指導教授：吳俊興. 博士. 中華民國一零一年七月.

(2) 目錄目錄................................................................................................................................. i 圖目錄.......................................................................................................................... iii 摘要................................................................................................................................ v ABSTRACT.................................................................................................................. vi 致謝詞..........................................................................................................................vii 1. 前言........................................................................................................................ 1 1.1. 雲端儲存.................................................................................................... 1 1.2. 質疑與挑戰................................................................................................ 2 1.3. 貢獻與成果................................................................................................ 4 1.4. 後續論文內容............................................................................................ 4 2. 相關研究................................................................................................................ 6 2.1. 雲端儲存.................................................................................................... 6 2.2. 對稱與非對稱加密法................................................................................ 6 2.3. 群體金鑰.................................................................................................... 7 2.4.. 3.. 4.. Erasure Code .............................................................................................. 7 2.4.1. Reed-Solomon Code ...................................................................... 9 2.4.2. Linear Combination Code ............................................................ 10 2.4.3. Luby-Transform Code.................................................................. 11 2.5. Shamir’s Secret Sharing ........................................................................... 13 系統介紹.............................................................................................................. 14 3.1. 系統原理.................................................................................................. 14 3.2. 系統架構.................................................................................................. 14 3.3. 基於安全性的架構.................................................................................. 16 3.4. 金鑰管理.................................................................................................. 18 3.5. 檔案散佈流程.......................................................................................... 18 3.6. 挑戰與問題.............................................................................................. 19 3.7. 編碼與解碼流程...................................................................................... 19 3.7.1. Reed-Solomon Code .................................................................... 20 3.7.2. Linear Combination Code ............................................................ 21 3.7.3. Luby-Transform Code.................................................................. 23 實例說明.................................................................................................. 24 3.8. 3.9. 小結.......................................................................................................... 26 系統分析.............................................................................................................. 27 4.1. Key Blocks 數目 ...................................................................................... 27 4.2. 空間成本.................................................................................................. 29 i.

(3) 時間成本.................................................................................................. 32 4.3.1. 不同 Erasure Code 在時間上的差異 .......................................... 33 4.3.2. Chunk Size 對時間上的影響 ...................................................... 34 4.3.3. 分享人數對時間上的影響.......................................................... 36 4.3.4. LT Code 還原檔案的問題 ........................................................... 37 4.3.5. 32-bit 的 LT Code ........................................................................ 38 4.4. 安全性分析.............................................................................................. 40 4.4.1. Key Blocks 組合數對安全性的影響 .......................................... 40 4.4.2. Key Blocks 外洩造成的影響 ...................................................... 42 4.4.3. Chunk Size 對安全性的影響 ...................................................... 43 4.4.4. 檔案中的特殊 Chunk 造成的影響 ............................................. 44 4.5. 三種 Erasure Code 的比較與適用狀況 .................................................. 45 5. 結論...................................................................................................................... 47 參考文獻...................................................................................................................... 49 4.3.. ii.

(4) 圖目錄圖 1-1 雲端儲存服務 -------------------------------------------------------------------------- 2 圖 1-2 檔案加密 -------------------------------------------------------------------------------- 3 圖 1-3 檔案切割 -------------------------------------------------------------------------------- 3 圖 2-1 對稱與非對稱加密法 ----------------------------------------------------------------- 7 圖 2-2 Erasure Code 編碼 --------------------------------------------------------------------- 8 圖 2-3 Erasure Code 解碼 -------------------------------------------------------------------- 10 圖 2-4 RS Code 編碼 -------------------------------------------------------------------------- 10 圖 2-5 RS Code 解碼 -------------------------------------------------------------------------- 11 圖 2-6 LC Code 的編碼方法----------------------------------------------------------------- 12 圖 2-7 LT Code 的編碼方法 ----------------------------------------------------------------- 13 圖 3-1 系統原理------------------------------------------------------------------------------- 14 圖 3-2 系統架構 ------------------------------------------------------------------------------- 15 圖 3-3 檔案上傳與分享流程 --------------------------------------------------------------- 16 圖 3-4 基於安全性的通訊協定 ------------------------------------------------------------ 17 圖 3-5 檔案切塊與展開 --------------------------------------------------------------------- 20 圖 3-6 RS Code--------------------------------------------------------------------------------- 20 圖 3-7 運用 LC Code 的編碼流程 --------------------------------------------------------- 22 圖 3-8 運用 LC Code 的解碼流程 --------------------------------------------------------- 22 圖 3-9 LT Code 的編碼與解碼 ------------------------------------------------------------- 23 圖 3-10 對應多個使用者的散播流程 ----------------------------------------------------- 25 圖 4-1 LC Code 可產生的金鑰數目(2n 個) ----------------------------------------------- 28. iii.

(5) 圖 4-2 LT Code 可產生的金鑰數目(2n 個) ------------------------------------------------ 29 圖 4-3 RS Code 的空間成本 ----------------------------------------------------------------- 30 圖 4-4 LC Code 的空間成本----------------------------------------------------------------- 31 圖 4-5 LT Code 的空間成本 ----------------------------------------------------------------- 32 圖 4-6 三種 Erasure Code 編碼時間比較圖---------------------------------------------- 33 圖 4-7 三種 Erasure Code 解碼時間比較圖---------------------------------------------- 34 圖 4-8 三種 Erasure Code 編碼時間比較圖---------------------------------------------- 35 圖 4-9 三種 Erasure Code 解碼時間比較圖---------------------------------------------- 36 圖 4-10 分享人數與編碼所費時間關係圖 ----------------------------------------------- 37 圖 4-11 LT Code 編碼與解碼所需 Symbols 的關係圖 --------------------------------- 38 圖 4-12 32-bit LT Code 編碼所需時間比較 ---------------------------------------------- 39 圖 4-13 32-bit LT Code 解碼所需時間比較 ---------------------------------------------- 40 圖 4-14 m 與破解所需嘗試組合數的關係圖 -------------------------------------------- 41 圖 4-15 m 對於安全性的影響(Field Size = 16 bits) ------------------------------------- 42 圖 4-16 m 對於安全性的影響(Field Size = 32 bits) ------------------------------------- 43 圖 4-17 Chunk Size 對於安全性的影響 --------------------------------------------------- 44. iv.

(6) 摘要雲端儲存服務可讓使用者將自己的資料儲存在遠端的伺服器裡，使資料享有資料備份、資料保密、動態儲存空間等好處，除此以外共享資料也是使用需求極多的服務，使用者可以將自己儲存在雲端空間的資料，分享給指定的一群人。然而，當使用者將資料儲存於雲端時，必須完全信賴供應商的方針，儘管現今供應商已有不少對策因應這些突發狀況，但使用者或許仍會希望能夠上第二保險；並非由供應商規劃，而是由自己保障資料的安全性。針對上述的問題點，我們提出一個簡單且實用的辦法，利用抹除碼對檔案編碼所產生的冗餘，可藉由使用者的規劃將這些冗餘分別儲存於不同雲端供應商所提供的空間，這樣的做法除了可避免存放於單一雲端供應商的檔案遭到破解或外洩的風險外，更可藉由將一部分的冗餘當作解密金鑰，令此份檔案必須結合雲端空間與做為解密金鑰的冗餘才能解開，進而達到保密的效果。除此之外，使用者可隨時產生複數個對應同一檔案的解密金鑰，能依照需求配合個人或多人使用。採用抹除碼分散存放資料到多台伺服器不僅能提高檔案的可獲得性，同時也可避免單一伺服器的資料毀損或外洩等風險。而當中做為解密關鍵的金鑰，則可依照使用者的意願存放在可信賴的地方，如個人電腦或是隨身碟，如此一來就能由使用者來限制檔案存取的權限，並根據其意願開放檔案的部分或全部讀取權限給其他人。本論文將探討此系統的效率、成本與安全性，並分析三種不同特性的抹除碼對系統的影響與其適用的場合。. 關鍵詞：雲端儲存、雲端安全、抹除碼、群體金鑰. v.

(7) ABSTRACT Using the service of cloud storage, users can store their file into the servers on Internet and have the advantage of data backup, data security, or dynamic storage space. Data sharing is also a very popular service; users can share data with some people who were trusted in. However, when users store their data in the cloud, they should follow the policies of cloud storage provider. In this situation, users may want to reinforce the security by themselves. For the requirement, we design and construct a scheme, which enable users to share and store data securely. Using erasure code, users can encode files and distributing those produced redundancies in the different storage providers, reducing the risk of saving data in the single storage provider. Most important of all, you can make one part of redundancies become the personal key of the encoded file. Further, you can produce many different keys which can decode the same encoded file, and distribute them for sharing files with the other ones. You can also distribute the keys into different devices like PC, flash drive...etc, with their choice. Thus file owners can limit the authority of file access by themselves, and control partial or all of the authority which others can access. In this paper, we will discuss the efficiency, the costs, and the security of our scheme. Besides, we will introduce the characteristics between different kinds of erasure code and analysis the influence to our scheme.. Key Words： Cloud Storage、Cloud Security、Erasure Code、Shared Key. vi.

(8) 致謝詞本論文能夠順利完成，首先必須感謝我的家人，在我求學期間不斷給予我支持與鼓勵，讓我能放心完成學業；同時也經常給予我建議，讓我能時時惕勵自己。接下來要感謝我的指導教授吳俊興老師，不僅在論文上給我許多細心的指導，在這兩年期間也經常在學術領域方面為我指導解惑，讓我在所學方面能有所精進，此外也要感謝薛智誠教授與陳建源教授的指導，使這篇論文得以更加完整。另外也要感謝實驗室的學長與學弟，雖然相處時間不久，但一同鑽研學問的時間對我也有莫大的幫助。. vii.

(9) 1. 前言隨著網際網路服務的日益普及和用戶網路頻寬的提升，人們對網路的依賴性愈來愈高，以往大多存放於個人電腦或儲存裝置的資料也漸漸會存放在網路上，因此便利、可靠的網路儲存服務平台也愈來愈重要。雲端的概念推行至今使得目前已有許多雲端儲存的服務出現，讓使用者能方便地存放自己的資料在網路上，而服務商則負責安全性與可靠性的保障，因此使用者不管何時何地，只要有能夠上網的電腦便能夠讀取自己存放於網路的資料。然而，網路的便利同時也帶來了許多弊病，然而在現今的時代裡，檔案的流傳與散播變得相當容易，萬一服務平台遭到攻擊導致重要資料外洩，則不管對使用者或是服務商來說都是一大傷害。因此，要如何提升儲存資料的保密及安全性，以避免資料被任意的複製、散佈甚至是竄改，遂成為重要的研究議題[7]。. 1.1. 雲端儲存雲端儲存是近年來隨著雲端計算的概念而衍生出的服務項目，使用者可將大量的資料存放在供應商代管的遠端伺服器中，不需自行添購伺服器或建置資料中心，對中小企業而言相當實用。雲端儲存更有許多優點：使用者只須依照自己使用的儲存空間來支付費用，不需自行處理資料管理、維護等的問題[4]。而隨著網際網路的普及與網路速度的增進，越來越多網路空間的服務因應而生，讓使用者可以將自己的資料儲存在遠端的伺服器裡。如圖 1-1，使用者保存在伺服器裡的資料，則受到供應商的保護，讓使用者享有資料備份、資料保密，以及無論何時何地，都能藉由可連接網路的裝置獲取個人的儲存資料。而除了可讓個人儲存與取得資料以外，共享資料也是使用需求極多的服務，使用者可以將自己儲存在雲端空間的資料，分享給指定的其他使用者。. 1.

(10) Cloud Storage Provider. 圖 1-1 雲端儲存服務. 1.2. 質疑與挑戰當使用者將資料儲存於雲端時，是由供應商來保障伺服器中資料的安全性，避免資料外洩或是遭到破壞。儘管現今已有不少對策因應這些突發狀況，但仍難以保證供應商能夠完美處理所有問題。因此本文策劃的系統，可讓使用者善加利用多個供應商所提供的雲端空間，將分割後的資料分散儲存於各空間，並能夠自己掌握檔案的分享或存取權限，則資料的安全性便能更上一層樓。總歸而言，本系統有以下的需求： 1) 存放於雲端的資料能夠是安全的，不管是雲端儲存供應商，或者是外來的攻擊者等等，若他們取得伺服器中的檔案時，無法順利解讀其中的內容。 2) 存放於雲端的檔案只有合法的使用者才能觀看檔案內容，其餘使用者無法觀看。而資料持有者(可能是使用者或雲端供應商本身)甚至可以限制合法使用者能夠觀看的檔案內容(部份或全部)。 2.

(11) 3) 資料持有者在分享資料時，能給予每個人獨特的一份金鑰，就如同軟體的授權金鑰一般，方便資料持有者追蹤與管理。這些金鑰雖然每份都不相同，但皆可對應到同一份檔案。事實上一些典型的做法可以達到以上我們的需求，最直覺的方法是對檔案加密，如圖 1-2：將加密後的檔案存放於雲端空間，如此一來便能藉由資料持有者掌握的解密金鑰 K1 來控管檔案的存取權限，並且可以保障檔案存放於雲端空間的安全；另一方法則是將檔案切割成數塊，並將它們分散儲存於不同的雲端空間，藉此分散單一雲端供應商遭到攻擊的風險，如圖 1-3。將檔案切割後可藉由資料持有者的安排，將不同檔案塊當做金鑰使用；例如將 1～3 塊存放於雲端空間，則第 4 塊便成了這份檔案的解密金鑰。. 1. 2. 加密. 1’. 2’. 解密. 1. 2. 3. 4. K1. 3’. 4’. K1. 3. 4. Encrypted File. File. File. 圖 1-2 檔案加密. 1 1. 2. 3. 4 File. 切割. 重建. 2 3. 1. 2. 3. 4 File. 4 圖 1-3 檔案切割. 然而這兩種做法都有其問題存在；以第 3 點要求來說，我們希望每個共享. 3.

(12) 檔案的使用者能夠擁有一份獨特的金鑰，而當資料持有者使用傳統加密法，他必須產生多組金鑰(由加密金鑰與解密金鑰組成)，並分別使用不同加密金鑰對檔案加密，再分配對應的解密金鑰給欲共享的使用者，這種方法缺點在於持有者欲分享給多少人就必須執行多少次加密，而且也會佔用大量的雲端空間來存放經由不同金鑰加密所產生的檔案，對系統效率來說並不佳。至於對檔案切割雖然大致上可滿足我們的 3 點要求，但最大問題在於若其中一個雲端空間故障，則資料持有者反而無法取回完整檔案。本論文的系統設計結合了加密檔案與切割檔案的特色，並能夠滿足以上的三點需求，藉此提升雲端儲存的安全性。. 1.3. 貢獻與成果針對上述的問題點，本論文中的系統利用 Erasure Code 對檔案編碼產生冗餘，並將這些冗餘分為共通區塊與金鑰區塊，共通區塊將存放於雲端空間；金鑰區塊則是存放於用戶端，做為還原檔案的關鍵；此份檔案必須結合公開區塊與金鑰區塊這兩種冗餘才能解開。而藉由規劃與分配這些冗餘，可達到我們所需求的效果： 1) 共通區塊可分散儲存於不同雲端儲存供應商所提供的空間，即使存放於單一供應商的資料遭到破解或外洩，也只能得到檔案的片段。 2) 金鑰區塊則可經由資料持有者(可能為使用者或雲端供應商本身)的授權存放於不同裝置(個人電腦、隨身碟等)，又或者是分發給其它使用者。擁有金鑰區塊的使用者或裝置在結合共通區塊與金鑰區塊之後，即可還原並得到原始檔案。 3) 利用 Erasure Code 可對檔案產生大量的冗餘，資料持有者可藉由指定數目與對象來對每個經授權的裝置(或使用者)分配一份獨特的金鑰區塊，這些金鑰區塊可用來辨識獲授權的對象。. 1.4. 後續論文內容接下來的論文將詳述我們的系統設計，在第二章將介紹相關研究以及背景 4.

(13) 知識，第三章則是講解系統的大致架構與當中細節，第四章則針對系統的效能和安全性進行評估並列出實驗數據，最後第五章則是結論與未來工作。. 5.

(14) 2. 相關研究 2.1. 雲端儲存隨著這些雲端儲存服務的改善與演化，越來越多使用者可以將自己的資料儲存在遠端的伺服器裡。而保存在伺服器裡的資料，則受到供應商的保護，讓使用者享有資料備份、資料保密、動態儲存空間，以及無論何時何地，都能藉由可連接網路的裝置獲取個人的儲存資料。市場上目前有 EMC 的 Atmos[10], IBM 的 Smart Business Storage Cloud[14]、ParaScale 的 Cloud Storage[21]、 Cleversafe 的 Distributed Storage Network[6]、Symantec 的 FileStore[22]、HP CloudSystem Matrix[12]、NetApp Dynamic Datacenter[20]等雲端儲存系統等，提供大型企業或雲端相關業者建置私有雲或公用雲檔案儲存的解決方案。除此之外，Amazon S3[1], Microsoft Azure[18], Google Cloud[11]等業者均有提供公有雲上的雲端儲存，也有第三方業者利用這些雲端儲存服務，提供有限免費、進階付費的公開網路儲存空間。學術上最近開始有複合雲相關研究，例如 MetaCDN[16]、MetaStorage[8]、SmartBox[24]、UbiCloud[25]等。這些系統多是採用 File-based 儲存方式，資料安全性多僅依賴基本加密來處理，多數著重在如何有效存取或利用公共雲，節點間如何有效資料交換或維持一致，則較少進行討論。. 2.2. 對稱與非對稱加密法對稱與非對稱加密法(Symmetric/Asymmetric Key Algorithms)通常被用在通訊上，發送方利用金鑰加密訊息後，再傳送給接收方用金鑰解密訊息，而對稱與非對稱的差別便在於，加密與解密時用的金鑰是否相同[23]。若為對稱加密，則加密與解密的金鑰皆為 K（見圖 2-1 (a)），若為非對稱加密法，則加密金鑰為 P，解密金鑰為 Q（見圖 2-1 (b)）。以非對稱加密法來說，解密方可以只公開金鑰 P 供人加密使用，所以在安全性上比對稱加密法還要高了一籌。對稱與非對稱加密法另一個特色在於，金鑰通常是以不同的接收方做為區. 6.

(15) 別，例如發送方同時傳送訊息給三個接收方，則發送方與接收方之間會有三組不同的金鑰。如此一來即使是同樣的訊息，不同的接收方也無法觀看其他人的訊息。. Plaintext. Encrypt with secret key K. Plaintext. Encrypted text. Plaintext. Decrypt with secret key K. Encrypt with public key P. Plaintext. Encrypted text. Decrypt with secret key Q. (b) Asymmetric key algorithm. (a) Symmetric key algorithm. 圖 2-1 對稱與非對稱加密法. 2.3. 群體金鑰群體金鑰(Group Key)讓同一份檔案能夠對應到多數個合法的使用權限 (License)，一般基本的作法是，不同的使用權限就使用不同的金鑰來加密檔案，但是如此不僅在製作加密檔案時沒有效率，在合法使用者間交互存取檔案時，也相當麻煩。因此，如果能夠讓不同的使用權限對應到同一個加密後的檔案，也就是一個檔案用一個金鑰加解密，而將這個解密金鑰授權給一群合法使用者使用。但是如果檔案被任意散佈時，卻無法確切得知是由哪一位使用者散佈。所以，再透過加入群組金鑰(Group Key)的概念，目的除了可以得知散佈檔案的使用者之外，亦可以改善檔案加解密金鑰的管理。. 2.4. Erasure Code Erasure Code(抹除碼)的概念是，假設原本的檔案內容由 k 個區塊(Block)組成，經由 Erasure Code 增加了 n 個區塊，如圖 2-2 所示。在這(k+n)個區塊中，只要任意取得 k’個，即可還原成原始的檔案內容[17]，如圖 2-3 所示；也就是說，最多可以容許 n 個區塊發生無法存取的情形；由此可得知 k 和 n 決定了檔案資料的可獲得性[9][13]。 7.

(16) ..… ..…. encode. ..…. k blocks (k+n) blocks. 圖 2-2 Erasure Code 編碼. ˇ ..…. ˇ. ˇ. ..…. ˇ ˇ. random pick k’ blocks then decode. ..… k blocks. (k+n) blocks. 圖 2-3 Erasure Code 解碼 Erasure Code 依照解碼所需的 k’可分為 Optimal Erasure Code 與 Near-Optimal Erasure Code；Optimal Erasure Code 在還原所需最低門檻 k’為 k，意即從(k+n) 個 Encoding Blocks 中任意挑選 k 個即可還原檔案； Near-Optimal Erasure Code 則需要 (1 + ε )k 個 Encoding Blocks 才可還原 ( ε > 0 ) ，但以時間成本來說 Near-Optimal 在編、解碼上所花時間會比 Optimal 還要少。 Erasure Code 的另一個重要參數為 Code Rate，Code Rate 的公式為 k/k’，代表原始訊息與全部訊息的比率，藉由 Code Rate 我們可以得知此次編碼中，原始訊息與冗餘訊息之間的比重。然而 Erasure Code 以 Code Rate 區分又可分為兩種：Fix-Rate Code 與 Rateless Code，Fix-Rate Code 在編碼前就要決定此次編碼所產生的 Encoding Blocks 數目，即為 k’，執行編碼後便會產生 k’個 Encoding Blocks，因此它的 Code Rate 是固定的；但 Rateless Code 每進行一次編碼只會產生一個 Encoding Block，可隨時依照編碼者的意願停止。一般來說 Fix-Rate Code 多用於保存靜態的資料，而 Rateless Code 則多用於通訊傳輸上。在後續小節中我們將會簡介本論文所用到的三種 Erasure Code，並會說明它. 8.

(17) 們分別屬於哪種 Erasure Code。. 2.4.1. Reed-Solomon Code Reed-Solomon Code(RS Code)由 Irving S. Reed and Gustave Solomon 於 1960 年提出[15]，被廣泛的應用於各種商業用途，最顯著的是在 CD、DVD 和藍光光碟上的使用；在數據傳輸中，它也被用於 DSL 和 WiMAX；廣播系統中 DVB 和 ATSC 也存在著它的身影；同時也是第六層標準 RAID 的重要成員。 RS Code 在 Coding Theory 中被歸類於 Linear Block Error-Correcting Code，編碼以 Linear Combination 的方式進行，並且將 k 個原始訊息轉換成 n 個編碼訊息(n>k)。而這些新添加入的訊息可以幫助接收端以一定程度的容錯率得到原始訊息。在編碼階段，假設原始訊息為一個 k × 1 的原始矩陣 E，首先由發送端隨機產生一個 size 為 n × k 的生成矩陣 G，接著發送端執行 G ⋅ E ，得到一個 n × 1 的訊息矩陣 A，接下來發送端便將這個訊息矩陣傳給接收端（圖 2-4）。在解碼階段，接收端收到的可能是完整或是殘缺的訊息矩陣 A’，不管如何，只要訊息矩陣的 row 數大於 n，則接收端就能利用 G ' −1 ⋅ A' 來得到原始矩陣（圖 2-5）。從這裡我們可以理解到，接收端必須要持有生成矩陣，才能進行解碼還原的動作，但若要讓發送端將生成矩陣傳給接收端，所要耗費的成本並不符合效益，所以一般的做法是讓發送端與接收端共享相同的 Generator Function，如此一來發送端只要傳送產生生成函數所需的參數，即可讓接收端也產生相同的生成函數了。由於在 Optimal Erasure Code 中，RS Code 是相當具有代表性的一種編碼方法，實作方便且有 Fix-Rate 的特性，因此在後續討論中將會探討以 RS Code 實作於本系統的優點與缺點。. 9.

(18) G α1,1 α1,2. …. α1,k. α2,1 α2,2. …. α2,k. E. A. E1 E2. A1 A2. … …. …. …. …. …. Ek. Ak’ αk’,1 αk’,2. αk’,k. …. G‧E = A. 圖 2-4 RS Code 編碼. G’. E1 E2. αa,1 αa,2. …. αa,k. Aa. αb,1 αb,2. …. αb,k. Ab. …. E. …. A’. …. k. …. …. …. Ek. G’‧A’ = E. 圖 2-5 RS Code 解碼. 2.4.2. Linear Combination Code Network Coding 是一種改良封包傳輸效率的技術，由 R. Ahlswede 等人於 2000 年提出[5]。網路編碼利用了在傳輸中所會經過的中繼節點，藉由讓這些節 10.

(19) 點進行編碼的動作來增加封包傳遞的可靠性，減低傳輸次數。 Christos Gkantsidis 在 2005 年將 Network Coding 的概念應用在點對點網路檔案的散播中，藉由讓網路中的每個節點(即使用者)執行編碼來增加檔案散播的效率。而其中的編碼方式便是利用線性組合(Linear Combination)加入抹除碼的原理，當越多使用者散播經過編碼後的檔案區塊，其他使用者就越容易湊齊復原檔案所需要的區塊數目。而該論文中提出了一個簡便的編碼方式(以下簡稱 LC Code)，其原理為將檔案分為 k 塊之後，隨機產生 k 個整數，並分別與 k 個區塊相乘，最後再將這些相乘的結果相加起來，如此一來便得到一份編碼後的區塊。由圖 2-6 可以看到產生編碼區塊的示意圖，E1 為第一次編碼所產生的區塊，裡面包含了以及 ,代表的結果，如果要復原檔案，必須至少重複這樣的動作 k 次，蒐集到 k 份編碼區塊之後，再利用高斯消去法等方法便可還原出。另外，為了避免相乘與相加的過程中數字溢位的問題，一切運算皆於伽羅瓦域(Galois Field)內計算。. B1. B2. B3. c1. ck. Bk. c’k. c’1. E1. E2. 圖 2-6 LC Code 的編碼方法本方法不僅便於實作，且具有 Fountain Code 的特性，讓執行編碼的時候不需事前決定欲展開的塊數，這個特性符合本系統在金鑰發送方面的需求。因此在本文的實際應用例子中將會以本編碼方式來舉例，屆時會再做更一進步的解說。. 2.4.3. Luby-Transform Code Luby-Transform Code(LT Code)是第一個符合 Fountain Code 特性的 Erasure Code，由 Michael Luby 於 2002 年提出[19]。以往的 Erasure Code 在編碼之前都 11.

(20) 必須指定欲展開的塊數，因此在使用時要先估算資料的遺失或損壞率，再決定要展開多少塊才較為划算，但 LT Code 的做法卻是每次編碼只會產生一塊編碼，這塊編碼是從所有的原始訊息中隨機挑選數個做 XOR 運算所得到(見圖 2-7)，而隨著傳送方不斷產生編碼塊並傳送給接收方的過程中，接收方只需要收到一定量的編碼塊便可停止接收並還原出原始訊息。正如同從噴泉中汲取水滴一般，水滴之間彼此可互相取代，接收方只要從中收到足夠的量即可。 LT Code 這種隨傳即收的特性讓它也被稱為 Rateless Code，但它的缺點在於無法確定每次還原所需要的編碼塊數；由於每次做 XOR 所挑選的原始訊息是完全隨機的，有時會發生覆蓋率不完全而導致某些原始訊息一直解不出來的情況。因此，LT Code 可適用於一些不需要完全精確的傳送資料的地方(例如即時影音傳送)。除此之外，LT Code 已有後續改良的 Raptor Code 於 2006 年發表[3]，目的在於改善 LT Code 還原不全的問題，但 Raptor Code 在編碼與解碼的時間複雜度已達 Linear，因此為了比較 Optimal Erasure Code 與 Near-Optimal Erasure Code 在時間上的差異度，本論文中我們還是以 LT Code 做為實測的對象。. 圖 2-7 LT Code 的編碼方法. 12.

(21) 2.5. Shamir’s Secret Sharing 機密共享是在金鑰管理方法上的一個重要課題，以一個大型的系統來講，如何保存與管理其中的解密金鑰關係到此系統的安全性，若將金鑰交給單一的管理者保管，不免有金鑰遺失或是遭到盜竊、外流的疑慮，於是較為安全的作法是交由多名管理者保管，然而若多名管理者所持皆為同一份金鑰，則金鑰外洩的機率反而變高了，機密共享機制便是為了解決這一方面的問題而產生。根據 Adi Shamir 於 1979 年提出的理論[2]，分派者將秘密分割成若干個子秘密給予多個互相不信任的參與者共享，使得這些參與者在出示足夠個數或滿足預先定義之資格子集合的子秘密後才可重建共享的秘密。由圖 2-8 可知，分派者將圖中的 Secret 分割成 4 個 Sub Secret 給予 4 個互相不信任的參與者共享，最後這些參與者在出示各自所擁有的 Sub Secret 後，才可重建共享的 Secret，如此一來攻擊者必須湊齊 4 個 Sub Secret，Secret 本身才會被破解。. 1 1. 2. 3. 4 Secret. 2 分割. 重建. 3. 1. 2. 3. 4 Secret. 4 Sub Secret. 圖 2-8 機密共享 Shamir 在 1979 年提出的門檻策略(Threshold Scheme)是指將 Secret 分割成 n 個大小相同的 Sub Secret，當收集超過 t 個 Sub Secret 就可還原出 Secret，反之則否。舉例來說，Secret {A, B, C, D}可分成{A, B}, {A, C, D}, {B, C, D} 3 個 Sub Secret，而收集者只要湊齊其中兩個便可還原 Secret。. 13.

(22) 3. 系統介紹 3.1. 系統原理在章節 2.5 我們介紹了 Shamir’s Secret Sharing 的原理，以本論文的系統來說，把 Secret 當成欲分享的檔案，經由分派者產生 Sub Secret，而收集者只要集滿一定數量的 Sub Secret 即可還原檔案，如圖 3-1。從圖中可以看到 Sub Secret 分為 Share Block 與 Key Block 兩種，Share Block 存放於雲端儲存空間，而 Key Block 則是由分派者傳送給指定的接收者，接收者便可利用 Share Block 與 Key Block 還原出檔案。. 1’ 2’ 1. 2. 3. 4 File. 3’ 編碼. Share Blocks. 解碼. 1. 2. 3. 4 File. 4’ …. n’ Key Blocks Encoding Blocks. 圖 3-1 系統原理. 3.2. 系統架構本章節將概略性的介紹我們的系統，首先將會介紹系統中所包含的角色，接下來再逐一說明各個角色所負責的工作。本系統包含了三個重要的角色：雲 14.

(23) 端儲放空間 (Cloud Storage Provider) 、金鑰管理者 (Key Manager) 與接收方 (Receiver)。如圖 3-2，Cloud Storage Provider 相當於雲端儲存供應商所提供的網路空間，可能為一個或多個伺服器，甚至是不同供應商所提供的空間；至於 Key Manager 則是資料持有者自身，Key Manager 藉由將 Shared Blocks 存放於 Cloud Storage Provider 與分配 Key Blocks 給 Receiver 來達到分享私密檔案的效果。. Cloud Storage Provider. Shared Blocks. Shared Blocks. Shared Blocks. Key Manager Key Block j Key Block i. Receiver i. Receiver j. 圖 3-2 系統架構圖 3-3 為系統運作流程，原始檔案經由 Key Manager 使用 Erasure Code 展開後，分成共通區塊(Share Blocks)與金鑰區塊(Key Blocks)，Share Blocks 被分別存放在 Cloud Storage Provider，而 Key Blocks 則是依照 Key Manager 的分配，傳送給 Receivers，包括了經授權許可的使用者或裝置(例如隨身碟、筆電)，Receivers 經過取得這兩種區塊的程序之後，便可執行 Erasure Code 的解碼來還原原始檔案。. 15.

(24) Key Manager. Cloud Storage Provider. Receiver i. Receiver j. (k-1) Share Blocks Request Key Blocks i & CSP info (k-1) Share Blocks Request Key Blocks j & CSP info (k-1) Share Blocks. 圖 3-3 檔案上傳與分享流程一般來說，Share Blocks 的檔案會比 Key Blocks 大上許多，若利用 Erasure Code 在理論上可將原始檔案展開到無限多塊的特性，將 Share Blocks 的數量設定在解碼的門檻前，也就是(k-1)塊，剩下所需的一塊則稱作 Key Blocks，被存放於 Key Manager 中，假設數目為 i，則這 i 塊 Key Blocks 都可用來當作同一檔案的解碼金鑰。. 3.3. 基於安全性的架構由圖 3-3 可以了解本系統的基礎流程，但此架構仍有一些安全性問題存在：如資料在網路中傳輸的時候皆為未加密的形式，如此一來可能會遭到有心人士攔截或竊聽；或是假冒 Key Manager 與 Cloud Storage Provider，傳給 Receivers 偽造的檔案。為了防範這些問題，我們更進一步的改善系統架構，如圖 3-4， Key Manager、Cloud Storage Provider 與 Receivers 分別有自己的 Public Key kaG、 16.

(25) kcG 與 kbGi，以及 Private Key ka、kc 與 kbi，在進行分享之前，Key Manager 必須先將檔案以 ka 加密後上傳至 Cloud Storage Provider，之後當 Receivers 向 Key Manager 發送要求檔案的請求時，會在訊息中附帶自己的 Public Key kbGi，除了當作之後 Key Manager 分送加密訊息用之外，也可以當成身份認證使用。經過 Key Manager 確認 Receivers 擁有權限後，Key Manager 便利用剛才收到的 kbGi 分別對訊息內容加密之後再傳給 Receivers，訊息內容包含了還原檔案不可或缺的 Key Blocks，以及 kaG 與 kcG。另一邊 Receivers 可從 Cloud Storage Provider 取得加密後的 Share Blocks，值得注意的是，這些 Share Blocks 是利用 ka 與 kc 加密而產生，Receivers 需要用到 kaG 與 kcG 來解密，如此一來便可以確認 Key Manager 與 Cloud Storage Provider 的身分正確性。. Key Manager. Cloud Storage Provider. Receiver i. Receiver j. (k-1) Share Blocks ka encrypted. kbGi. Key Blocks i & CSP info kbGi encrypted. (k-1) Share Blocks kakc encrypted kbGj. Key Blocks j & CSP info kbGj encrypted. (k-1) Share Blocks kakc encrypted. 圖 3-4 基於安全性的通訊協定本系統的最大限制在於 Cloud Storage Provider 必須也參與加密 Share Blocks 的動作，這麼做是為了確保 Receivers 不會遭到假冒的 Cloud Storage Provider 欺. 17.

(26) 騙，如果 Key Manager 或是 Receivers 完全信任 Cloud Storage Provider，則可省略此一步驟。. 3.4. 金鑰管理要能夠有效管理儲存檔案的散播，必須掌握金鑰的管理，以下會介紹本系統的金鑰產生與散佈的流程。根據前文所提，Erasure Code 的原理在於將原始檔案分為 k 個區塊並展開成 (k+n)份之後，從(k+n)份中取得任意 k 份(此處為線性編碼的情況)，則便可以還原成原始的檔案。反過來說，萬一只取得(k-1)塊，則無法還原檔案。本系統便是利用 Erasure Code 的這個特性，將展開後的一部分檔案區塊當作金鑰使用，而這一部份的檔案區塊則是金鑰管理的重點，使用者可以將這些區塊存放於信賴的地方，如網路空間或是個人電腦，甚至也可以自行定期改變存放位置，增加安全性。除此之外，由於 Erasure Code 在編碼時會將檔案分成許多碎塊(Chunk)，並分別對這些 Chunk 進行編碼的動作，利用這一點可以產生專屬於每個不同 Chunk 的金鑰。如此一來，使用者便能夠藉著開放檔案可讀取的部份，來規範接收者讀取權限的高低。根據前文提過的對稱與非對稱加密法，以這兩種加密法來比較的話，金鑰的產生是根據來源方想要散佈給多少接收者而改變。每多散佈給一個接收者，就要多產生一組金鑰。而本系統產生的金鑰則是以不同的檔案內容而改變，彼此無法共通使用。至於產生的數量也是以使用者想要散佈給多少人而定。. 3.5. 檔案散佈流程這一章節將更加詳細敘述檔案散播的過程。由中可以得知，檔案首先經由 Erasure Code 展開，並且產生(k-1+i)份編碼區塊，而系統又將這些編碼區塊區分成(k-1)個 Share Blocks 和 i 個 Key Blocks，這串流程相當於利用 Erasure Code 將 k 份展開成(k-1+i)份的流程。接下來，接收者先從 Cloud Storage Provider 上取得(k-1)個 Share Blocks 之 18.

(27) 後，再通過認證來取得剩下的那 1 個 Key Blocks，Key Manager 將會根據使用者的不同，而從先前產生的 i 個 Key Blocks 中(K1,K2,…,Ki)，發送給使用者一個專屬於他的 Key Blocks。接收者湊齊了 Share Blocks 與 Key Blocks，也就是(k-1+1)個區塊之後，即達到了 Erasure Code 還原檔案的門檻，如此一來便可還原出檔案。. 3.6. 挑戰與問題以典型的 RS Code 來說，最常見的是(255,223) Code，也就是將 223 個 8-bit 的輸入符號展開成 255 個 8-bit 的輸出符號，換算成 Chunk Size 約為 1.7KB。由此可見，若要對一份完整的檔案以 Erasure Code 編碼，必須切成許多 Chunk，並分別對這些 Chunk 的 Key Block 進行管理，而這些工作就必須由 Key Manager 來負責。除此之外，Receiver 在收到 Shared Blocks 與專屬的 Key Block 之後需執行 Erasure Code 的還原程序才能得到原始檔案。因此我們必須衡量 Key Manager 與 Receiver 之間所需執行的工作效率，例如 Erasure Code 編碼與解碼的時間、因編碼所產生的額外冗餘大小，或是檔案是否有被破解的風險等等，這些問題我們在第四章會有更進一步的討論。. 3.7. 編碼與解碼流程本章節將詳述系統的編碼流程，由圖 3-5 可知，在對整份檔案進行編碼之前，系統會先對檔案進行「分割」與「切塊」的動作，「分割」指的是將檔案取一部份出來當作執行編碼的對象，即圖的 Chunk 部份。接下來是「切塊」，將 Chunk 分割出來後，會再切成 k 個區塊(Block)進行編碼，而 k’則代表了欲復原檔案所需蒐集的最少區塊數目，接下來我們會套用前文在 Erasure Code 章節所提到的 RS Code、LC Code，以及 LT Code 來實際解說編碼與解碼的流程，並列舉這三種編碼的特性與優缺點。. 19.

(28) whole file chunk split into k blocks B1 B2 B3. Bk. …. encoding scheme or. RS Code. or. LC Code. LT Code. 圖 3-5 檔案切塊與展開. 3.7.1. Reed-Solomon Code RS Code 是定長碼，這意味著在編碼之前就必須決定展開的區塊數目，由圖 3-6 可以看到， E 為欲傳送的原始訊息， G 為生成矩陣， G ⋅ E = A ， A 為實際在網路中傳送的訊息，而解碼則是以 A 的子矩陣 A' 計算 G '−1 ⋅ A' ，只要 A' 含有至少 k 個元素，就可以順利解出 E 。. G. A. E. A1. 1 α1 α12. …. α1k-1. E1. A2. 1 α2 α22. …. α2k-1. E2. …. …. 1 αk’ αk’2. …. …. …. …. … Ak’. …. αk’k-1. 圖 3-6 RS Code 以下將編碼與解碼的流程以算式表示： 20. Ek.

(29) 1  1 1   1 . α1 α2 α3 . α12  α1k −1    E1   A1  α 2 2  α 2 k −1      E2 A2 α 3 2  α 3 k −1    =   . α k ' α k '2.       E k −1  k   α k '  .      Ak ' .     寫成簡式為 G ⋅ E = A ， G 為 Key Manager 產生的一個 k × k ' 生成矩陣，該矩  陣必須符合 Vandermonde Matrix，這是為了確保計算 G −1 時能夠百分之百成功，    而 A 則是兩個矩陣相乘的結果矩陣。進行編碼結束後，將 G 與 A 存放於 Cloud  Storage Provider，至於存放時所採用的格式，若令 1 ≤ m ≤ k ' ， wm 為 G 的第 m 個 row，則存放在 Provider 的每一份編碼區塊皆是以 [wm , Am ] 的格式保存。.   接下來是解碼的部份，RS Code 的解碼流程很簡單，只要計算 G '−1 ⋅ A' 即可，       其中 A' 為 A 的子矩陣，而 G ' 則對應 A' ，是 G 的子矩陣，需要注意的是 A' 的元素個數必須至少有 k 個，否則解碼無法成功。 RS Code 因為在編碼之前就必須決定展開的區塊數目，這意味著能夠產生的 Key Blocks 數量也受到限制，所以不太適合用於不定量且多數接收者的情形。但另一方面來說，卻可藉由限制 Key Blocks 的數量，避開 Key Blocks 遭到暴力破解的機率，較適用於個人儲存空間(允許存取者只有自己)的情形。. 3.7.2. Linear Combination Code LC Code 雖然屬於 Optimal Erasure Code，但又具有 Fountain Code 的特性，以下是進行編碼的算式： a2  ak   E1   A1  b2  bk   E2   A2  = c2  ck                 Ek   Ak '      寫成簡式為 G ⋅ E = A ， G 為 Key Manager 進行 k ' 次編碼所產生的一個 k × k '  隨機矩陣， A 則是兩個矩陣相乘的結果矩陣。LC Code 與 RS Code 的計算式雖 a1 b  1  c1  . 21.

(30) 然相像，但差異最大的地方在於 LC Code 可以任意決定 k ' 的大小(見圖 3-7)，而且只要 Chunk 相同，無論何時產生的 Encoding Symbols 皆可通用。   編碼結束後，Key Manager 將 G 與 A 存放於 Cloud Storage Provider。至於存  放時所採用的格式，若令 1 ≤ m ≤ k '，wm 為 G 的第 m 個 row，則存放在 Key Manager 的每一份編碼區塊皆是以 [wm , Am ] 的格式保存。. B1. B2. …. B3. Bk. encoding scheme a1. B1 +a2. B2. +...+ak. Bk. =. A1. b1. B1 +b2. B2. +...+bk. Bk. =. A2. c1. B1 +c2. B2. Encoded +...+ck. Bk. =. A3. block amount : k’. ….. 圖 3-7 運用 LC Code 的編碼流程接下來是解碼的部份，解碼這個動作相當於要解一組有 k 個變數的線性方程組，於此我們利用高斯消去法來執行。圖 3-8 描述的是本系統解碼的流程。. (a1,a2,..ak, A1 ). random pick k packets from k’ packets. (b1,b2,..bk, A2 ). ….. B1 recover the original chunk. 圖 3-8 運用 LC Code 的解碼流程. 22. …. Bk.

(31)  解碼之前必須要從編碼區塊裡面蒐集任意不重複的 k 個區塊，將這些區塊視為 G      與 A 的子矩陣，並將其寫做 G ' 與 A' 。而計算 G '−1 ⋅ A' ，即可還原出原本的 k 塊檔  案，也就是 E 。. 3.7.3. Luby-Transform Code LT Code 與 LC Code 同樣擁有 Fountain Code 的特性，但它屬於 Near-Optimal Erasure Code，圖 3-9 分別代表 LT Code 的編碼與解碼流程，左側方塊代表原始檔案區塊，右側方塊則代表進行編碼所產生的區塊，在進行解碼時，除了需要收集足量的編碼區塊以外，也要擁有這些區塊所含的 degree 數，以及它們是經由哪些原始區塊編碼產生的（記錄在 vector 裡）以下是進行編碼的三個步驟： 1)隨機選出一個正整數 degree d m ， 1 ≤ d m ≤ k 。 2)從 1 ~ k 中選出 d 個不重複的數字 vm = {i1 , i2 ,  id } 。. d. 2. 1. 2. 2. 1. 2. 1. v. (1100). (0100). (0011). (1001). (0010). (0101). (1010). 圖 3-9 LT Code 的編碼與解碼. 23.

(32) 3)最後執行 Ei1 ⊕ Ei2 ⊕  ⊕ Eid ，得到 Encoding Symbol Am ，令進行 k ' 次編  碼，則可得到 A = [A1 , A2 ,  Ak ' ] 。.    編碼進行時，Key Manager 必須將 d = [d1 , d 2 ,  d k ' ]與 v = [v1 , v2 ,  vk ' ]，以及 A 儲存於 Cloud Storage Provider，若令 1 ≤ m ≤ k ' ， d m 、 vm 與 Am 各代表該矩陣的的第 m 個元素，則存放在 Key Manager 的每一份 Encoding Symbol 皆是以. [d m , vm , Am ] 的格式保存。至於解碼的部份，同樣分為三個步驟： 1)首先找出 d m = 1 的 Encoding Symbol（這代表該 Encoding Symbol 恰巧等於某個 Input Symbol）。 2)對所有包含該 Input Symbol 的 Encoding Symbol 做 XOR。 3)重複第一步驟，直到所有 Input Symbol 都還原為止。由於進行第二步驟極有可能產生新的 d m = 1 的 Encoding Symbol，所以理論上這個循環會一直持續到所有 Encoding Symbol 的 degree 皆等於 1，但反過來說，一旦這個循環中斷，就必須閒置到新的 degree 為 1 的 Encoding Symbol 進入，才能繼續進行解碼。為了避免解碼的過程太容易中斷，Michael Luby 在論文中提出以 Soliton Distribution Function 來產生 degree，如此一來可大幅減少解碼中斷的情形。. 3.8. 實例說明在本章節將運用前文所提的 LC Code 來舉例並講解系統的完整流程，圖 3-10 代表的是檔案來源(Source)將一份完整的檔案(080、151、202、103)發送給三名使用者(Client A、Client B、Client C)的過程，在這邊檔案來源泛指存放檔案  的伺服器，而方格中的數字則是代表編碼區塊儲存或傳送的格式，也就是 G ' 與    A' ，例如(2,1,0,1)即屬於 G ' ，414 則是屬於 A' 。在開始發送檔案之前，來源先執行編碼的流程，利用 080、151、202、103 這四塊(k=4)原始檔案區塊產生六份編碼區塊，而其中有三份(k-1=3)屬於 Share. 24.

(33) Blocks，這三份區塊可供人隨意下載，但仍未達到抹除碼復原檔案的所需的門檻。另外的三份(i=3)屬於 Key Blocks，Key Blocks 的產生根據使用者的數量而定，從圖 3-10 可以看到有三名使用者(Client A、Client B、Client C)，因此來源便產生 SA1、SB1、SC1，代表了屬於 Client A、B、C 的獨一無二的 Key Blocks。使用者必須通過認證，才能從來源處獲得 Key Blocks，當使用者獲得 Key Blocks 與 Share Blocks 之後，就能執行 LC Code 的解碼動作，將原始的檔案復原。在圖 3-10 中，以使用者的角度觀看檔案下載與復原的流程如下，Client A 決定自己欲下載的檔案後，首先會先下載該檔案的 public file，也就是 Share Blocks 的部份，這三塊分別是[(2,1,0,1),414]、[(1,2,1,1),687]，與[(1,1,0,1),334]，接著必須等待來源的認證結果，若是通過，則來源會回傳屬於 Client A 的個人金. Source. Shared Blocks 414 (2,1,0,1) 687 (1,2,1,1) 334 (1,1,0,1). 080 151 202 103. KA1. 305 (0,0,1,1). Client A. KB1. Client B. KC1. recover. 414 (2,1,0,1) 687 (1,2,1,1) 334 (1,1,0,1) 639 (1,1,1,2). recover. 080 151 202 103. 圖 3-10 對應多個使用者的散播流程. 25. 639 (1,1,1,2). Client C. 414 (2,1,0,1) 687 (1,2,1,1) 334 (1,1,0,1) 536 (1,1,1,1). 414 (2,1,0,1) 687 (1,2,1,1) 334 (1,1,0,1) 305 (0,0,1,1). recover. 536 (1,1,1,1).

(34) 鑰 SA1，即為[(0,0,1,1),305]這一塊，當 Client A 擁有四塊編碼區塊後，便可組合 2  1 成矩陣 G ' =  1  0. 1 2 1 0. 0 1 0 1. 1 414    687  1  ，接著再進行 G '−1 ⋅ A' 的計算，便可得到與 A' =  334  1    1 305 . 080   151  。 E= 202   103  另外，金鑰的產生其實可以是連續，也可以是不連續的，圖中只顯示了三名使用者的情形，若接下來更多使用者向來源要求檔案的話，來源依然可以用 080、151、202、103 這四塊原始檔案區塊進行編碼，進而產生更多 Key Blocks。預先產生一定數量的金鑰可以縮短來源回應使用者的時間，但也會佔掉多餘的空間，這是一個必須在時間跟空間之間做取捨的問題。. 3.9. 小結在第 3 章裡我們已詳述本系統的架構及流程，本系統結合了章節 1.2 所提出的傳統加密與單純切割的做法，利用 Erasure Code 對檔案編碼—相當於對檔案加密，而將編碼後的檔案分散儲存在不同的雲端空間則相當於對檔案切割。而本系統也符合章節 1.2 的三項安全性需求：保障檔案的安全性、唯有合法使用者才可讀取檔案，以及可分配給每個合法使用者一份金鑰。. 26.

(35) 4. 系統分析本章節將探討系統中會影響效能的各種因素，並以實驗數據為輔助來講解，如 Erasure Code 的編碼與解碼所需時間、編碼區塊所佔的額外空間、能夠產生多少 Key Blocks，以及本系統的安全性。另外實驗的系統作業環境是 64-bit 的 Windows 7，系統配備為 Intel Core i5-2400、CPU3.10GHz，RAM 4G，所使用的程式語言為 Matlab，版本為 7.1 版。. 4.1. Key Blocks數目 Key Blocks 數目相當於 Key Manager 想要分享檔案的人數，對本系統來說也是一個重要的問題，而我們的要求在於每個接收者都能拿到獨一無二的 Key Blocks，這也代表了不會有其他人擁有重複的 Key Blocks，但如前一章節所說，系統必須將 G,m 限定在某個範圍以內，這也代表了實際上能產生的 Key Blocks 數目是有限的，於是本章節藉由實際計算根據檔案大小與有限域的不同，來推斷大致能產生的 Key Blocks 數目。以 RS Code 來說，在編碼之前所產生的生成矩陣關係到能夠產生的 Key Blocks 數目。由圖 3-6 可以知道，決定生成矩陣的變數為 α1 ~ α k ' ，因此假設每個變數長度為 p-bit，所有可能的組合數就是 2 p 種；若以每個變數長度為 8-bit 來看，總共只有 28 = 256 種不同的 Key Blocks，如果想要分享檔案給很多人的話，RS Code 並不太適合。但根據 RS Code 的特性，不同生成矩陣所產生的 encoding symbols 彼此之間不可通用。舉例來說，當 Key Manager 對 k 塊 Input symbols 編碼得到 k 塊 Encoding symbols 之後，若將(k-1)塊 Encoding symbols 儲存在雲端，剩下來的那 1 塊 Encoding symbol 便會成為能夠還原原始檔案的唯一 Key Block，當使用者欲將檔案讀取權限限制在自身的時候，使用 RS Code 就是一個很好的選擇。因為如此，再下一個章節，我們將以 k 塊 Input symbols 展開成 k 塊 Encoding symbols 來當成實驗測量的條件。以 LC Code 來說，Key Blocks 的數目受到 k 的數量影響，因此會隨著檔案大小成長，另一方面則是隨著有限域的擴大而增加，令原始區塊有 k 塊，每個 27.

(36) 係數的長度為 p-bit，則所有可能的組合數共有 p k 種，圖 4-1 為計算結果。圖的Ｘ軸為原始檔案大小，而 Y 軸為能夠產生的編碼區塊數目。由圖中可以看出，即使 Chunk 很小(小於 50 Bits)，但只要有限域的範圍夠大，仍然可以產生相當多數量的編碼區塊，足以應付大量的使用者需求。實際上，Key Blocks 的總數量還必須減去那些用來當作 Share Blocks 的數. 圖 4-1 LC Code 可產生的金鑰數目(2n 個) 量，但那些數量跟實際能產生的編碼區塊相比實在過於微小，以 50 bits，p=16 來看，可用的 Key Blocks 比例約等於 (216000 − 16000) / 216000 ，幾乎接近 100%，所以一般來說並不會發生 Key Blocks 數目不足的問題。以 LT Code 來說，Key Blocks 的數目同樣受到 k 的數量影響，因此隨著檔案大小成長，與 LC Code 不同的地方在於 LT Code 只依賴 Input Symbols 之間的 XOR 組合，能夠產生的 Key Blocks 數較少，但優點在於編碼速度較為迅速，圖的Ｘ軸為原始檔案大小，而 Y 軸為能夠產生的編碼區塊數目。令原始區塊 k 塊，總共組合數即為 2 k 種。由圖 4-2 可以看出，即使 Chunk size 低於 100 bits，能夠產生的 Key Blocks 數仍然達到 2100 以上，因此儘管 LT Code. 28.

(37) 能夠產生的 Key Blocks 數較 LC Code 少，但它仍然能夠用於分享檔案給多數使用者。. 圖 4-2 LT Code 可產生的金鑰數目(2n 個). 4.2. 空間成本 Erasure Code 在編碼後所產生的 Encoding Symbols 會比未經編碼的檔案塊還要大，原因在於 Encoding Symbols 裡包含著 Erasure Cods 進行解碼還原檔案所需要的資訊片段，因此我們需要計算進行 Erasure Code 編碼時所佔用的空間成本，來作為評估本系統效能的一環。空間成本會隨著 Encoding Symbols 的數量而增加，這意味著當 Key Manager 想要產生更多 Key Blocks 時，也會增加空間成本。在本章我們會計算利用 Erasure Code 將 k 塊原始區塊展開成 k 塊編碼區塊後，相較於原始區塊所額外佔用的空間，也就是「k 個編碼區塊－k 個原始區塊」。首先以 RS Code 來說，編碼前與編碼後的 Symbols 兩者大小並無不同，但必須儲存生成矩陣作為還原檔案時的依據，因此 RS Code 與不使用 Erasure Code 29.

(38) 的情形相比，空間成本的因素在於生成矩陣的大小。由圖 3-6 可以看出生成矩陣的大小是以原始檔案長度 k ，以及編碼檔案長度 k ' 所決定，所以我們可以簡單推算出生成矩陣所佔的空間為「 k × k '× 每個矩陣元素所佔的 bits」。然而，由於 RS Code 的生成矩陣本身必須符合 Vandermon-Matrix 形式，所以只需要知道矩陣的第一列就能推算出後面的元素，由此可知在儲存生成矩陣時，只需要儲存第一列的元素即可，依照這個原則我們可以推算出 RS Code 的生成矩陣所佔的空間為「 1 × k '× 每個矩陣元素所佔的 bits」。圖 4-3 顯示了公式推算結果，X 軸為檔案 Chunk Size，Y 軸為編碼產生的額外空間(與未編碼做比較)，另外為了比較每個 Symbol 的大小是否會造成空間成本差異，我們在圖中描繪了兩條線，分別代表 p=16(每個 Symbol 16bits)與 p=8(每個 Symbol 8bits)。然而從圖表顯示這兩條線是重疊的，亦即空間成本完全一樣，這是因為擴增 Symbol 大小的同時，會減少 k 的數目導致空間成本下降，以 Chunk Size 160 bits 舉例來說，當 p=16 時，k=160/16=10；p=8 時 k=160/8=20，k 越小代表成本越低，但 Symbol 大小越大則成本越高，此一增一減導致了兩條線完全. 圖 4-3 RS Code 的空間成本. 30.

(39) 重疊，所以我們可以得到 Symbol 的大小並不影響空間成本這一個結論。接下來看 LC Code，與原始區塊相比，LC Code 所需的額外空間在於係數，也就是 wm 的部分，令原始區塊有 k 塊，欲展開 k ' 塊，每個係數佔 p-bit，則 LC Code 的空間成本為 k × p × k ' bits。圖 4-4 為計算結果，X 軸為檔案 Chunk Size，Ｙ軸為 wm，即編碼所佔用的額外空間。本文假設每一 Symbol 固定為 16 bits 與 8 bits，所以隨著檔案大小的上升，k 的數目也會增加，而 k 的數目增加則代表了系統需要產生的係數，也就是 wm 的大小也提高了。除此之外，當系統在隨機產生 wm 的時候，必須讓係數落在伽羅瓦域之內，寫成 GF ( p ) ， p 代表有限域的大小介於 0 ~ (2 p − 1) 內，若 p 越大，則需要用越多的 bits 來表示。圖 4-4 顯示三條曲線，分別是 p = 16 、 p = 8 與 p = 4 。從 4.1 可以知道 LC Code 可能產生的 Key Blocks 組合數相當多，因此這裡可以選擇 p = 4 來盡量降低空間成本。. 圖 4-4 LC Code 的空間成本與 LC Code 相同，LT Code 在進行編碼後，Encoding Symbols 需要含有該 Symbol 的資訊，包括 Degree 數與 Input Symbol vector(如圖 3-9)，然而雖然兩種 31.

(40) 編碼所需的資訊雖然相同，LT Code 所佔的空間卻比 LC Code 少很多，這是因為 LT Code 只是純粹進行 Input Symbols 之間的 XOR 運算來產生 Encoding Symbols，所以在 Input Symbol vector 中只需要記錄哪些 Input Symbols 參與即可 (1 或 0)。因此令原始區塊有 k 塊，欲展開 k ' 塊，則 LT Code 的空間成本為 k × k ' bits (Degree 數太小所以不計)。從以上結論可知，影響 LC Code 的空間成本最直接的因素在於 k，也就是 Input Symbols 的數量，由圖可以發現 p=8 時的空間成本比 p=16 還多，這是因為當 Chunk Size 相同時，p=16 的 k 會比 p=8 還少，連帶降低了空間成本。. 圖 4-5 LT Code 的空間成本. 4.3. 時間成本時間成本以本系統而言是指使用者利用 Erasure Code 進行編碼與解碼的這兩個程序，影響因素除了使用的 Erasure Code 種類，還有 Field Size、Chunk Size、 File Size，以及欲產生的 Key Blocks 數等，至於網路傳輸速度則不在本文討論範. 32.

(41) 圍內。. 4.3.1. 不同Erasure Code在時間上的差異 Erasure Code 若以編碼與解碼所費的時間來分的話可分為時間以線性成長的 Optimal Erasure Code 與非線性成長的 Near-Optimal Erasure Code，一般來說 Near-Optimal Erasure Code 所耗費的時間會比 Optimal Erasure Code 少許多，我們在本系統中所採用的 RS Code 與 LC Code 為 Optimal Erasure Code，LT Code 則為 Near-Optimal，它們之間的時間差異可在圖 4-6 中看出。. 圖 4-6 三種 Erasure Code 編碼時間比較圖圖 4-6 的 X 軸為 File Size，Y 軸為編碼所花的時間，從這三條曲線中可以得知 LC Code 所費的時間最多，LT 則是最少。圖 4-7 表示的則是三種 Erasure Code 的解碼時間，X 軸與 Y 軸皆與圖 4-6 相同，從圖中一樣可以得知 LT Code 速度最快，而 LC Code 速度最慢。除此之外，我們還可以得知不管是哪一種 Erasure Code，其解碼時間皆比編碼還要長許多。由於解碼程序是在接收端進行，因此為了盡量降低接收端的負擔，在考慮 Erasure Code 的搭配時我們應以解碼所 33.

(42) 耗費的時間為主要考量。總結來說，LT Code 不管是在編碼或解碼都非常迅速，因此較適合處理大一些的檔案(>10MB)，速度排名第二的 RS Code 則以 10MB 以下為佳，至於速度最慢的 LC Code，則適合處理一些較小的檔案(<1MB)。. 圖 4-7 三種 Erasure Code 解碼時間比較圖. 4.3.2. Chunk Size對時間上的影響我們已討論過 File Size 對於編碼、解碼的影響，但仍有其他會影響時間的因素，本系統對於編碼、解碼的程序皆是以 Chunk 為單位，上一章節我們把 Chunk Size 固定，因此隨著 File Size 越大，編解碼所費的時間也理所當然地增加(因為 Chunk 的數量變多)。然而以相同 File Size 來說，若提高 Chunk Size，則單一 Chunk 所費時間變高，但整體 Chunk 數量變少，若降低 Chunk Size 則反之。由此可知， Chunk Size 的大小對 Erasure Code 所耗時間的影響是較難預測的。圖 4-8 為在固定 File Size(10KB)下，三種 Erasure Code 針對不同 Chunk Size. 34.

(43) 所需花費的時間，從圖中一樣可以看出 LT Code 最為省時，LC Code 最為費時。然而最重要的是，隨著 Chunk Size 的增加，花費時間也跟著上升這一點，此項事實證明了在同樣 File Size 下，切成越多 Chunk 在時間上越快。因此如果想降低時間成本，把 Chunk 的 Size 壓低是一個有效的做法，但這種方法也有缺陷存在，由於 Chunk Size 會影響到 k—單一 Chunk 所包含的元素數量，當壓低 Chunk Size 時，k 的數目也會跟著下降並連帶影響到能夠產生的 Encoding Symbol 組合數，因此我們在實驗中以 Chunk Size 1024 bits 為最低底限。. 圖 4-8 三種 Erasure Code 編碼時間比較圖圖 4-9 表示了在不同 Chunk Size 下三種 Erasure Code 解碼所需的時間，由於解碼花的時間與編碼相較起來多上許多，因此我們也較容易從曲線上看出時間的成長，從圖上可以清楚看出 LC Code 與 RS Code 是呈線性成長，LT Code 的曲線則最為平緩，然而從曲線上可以發現 LT Code 的花費時間有時不太規律，這是因為在編碼的過程挑選 Input Symbols 的數量完全是隨機決定，導致每次編碼所需時間不固定；另外進行解碼有時也會因為 Encoding Symbols 對 Input Symbols 的覆蓋率不佳致使每次解碼所需 Encoding Symbols 的數量不定(因此時間也不一定)，總歸來說「不穩定」便是 LT Code 的最大缺點。 35.

(44) 圖 4-9 三種 Erasure Code 解碼時間比較圖. 4.3.3. 分享人數對時間上的影響在前面的章節中，我們量測了 Erasure Code 在編碼與解碼所花的時間，以編碼的情形是從 k 塊 Input Symbols 展開成 k 塊 Encoding Symbols，解碼則是將 k 塊 Encoding Symbols 還原成 k 塊 Input Symbols(LT Code 例外)，然而這些都只有考量分享人數只有 1 人的情形，若 Key Manager 想要將檔案分享給更多的人，則編碼時就必須展開比 k 更多塊，例如分享給 100 人就必須展開成(k+99)塊，分享給 500 人就要展開成(k+499)塊…等，而本章節會針對不同 Erasure Code 在分享給多人時所需花費的時間進行評估。圖 4-10 我們以 File Size 10KB、Chunk Size 1024 bits 為固定因素進行實驗， X 軸為分享人數，若分享人數為 100 則代表 Erasure Code 進行編碼展開了(k+99) 塊，Y 軸則是花費的時間，圖中顯示了 LC Code 與 RS Code 的實驗結果，從圖上的數據可以看出 LC Code 的花費時間隨著分享人數的增加而線性上升，而 RS Code 雖然也有上升，但區現相對的就十分平緩，從實驗結果來看 LC Code 在分 36.

(45) 享人數眾多時的時間成本上升的很迅速，但若將分享人數控制在 1000 人以內的話，基本上還不會造成太大的問題。至於 LT Code 雖然在時間成本上是最低的，但考量到 LT Code 每次解碼還原所需的 Encoding Symbols 數目皆不同，因此無法準確推測出利用 LT Code 分享給多人時所需要展開多少 Encoding Symbols，針對這個問題，我們將於下一節深入討論。. 圖 4-10 分享人數與編碼所費時間關係圖. 4.3.4. LT Code還原檔案的問題從前面的章節可以得知 LT Code 雖然在時間成本上佔有很大的優勢，但同時也存在著不穩定的缺點，因此 Key Manager 必須產生更多的 Encoding Symbols 數來盡量確保能夠成功解碼。實驗以單一 Chunk 為量測單位，Chunk Size 從 1024 bits～8192 bits，Field Size 固定為 16 bits，圖 4-11 為每個 Chunk 測試 10 次並取平均值的量測結果，從圖. 37.

(46) 中可以得知每次解碼所需的 Encoding Symbols 數大約落在 k*1.2～k*1.4 中間，隨著 k 的成長而曲線有變緩的趨勢，最後約落在 k*1.25。這樣的結果以 k=500 來看，Encoding Symbols 至少要 625 塊才能解碼成功，以空間成本來看依然是略為過多。造成這個問題的原因主要在於隨機產生 Encoding Symbols 時無法將 Input Symbols 的覆蓋率提升到 100%所導致，後續已有針對此問題改良而提出的方法—即是 Raptor Code；利用兩層 Erasure Code 的方式可有效成功降低解碼所需的倍數。. 圖 4-11 LT Code 編碼與解碼所需 Symbols 的關係圖. 4.3.5. 32-bit的LT Code 從前面的實驗可以證明時間成本隨 k 的數量上升，而改變 k 的因素除了 File Size 以外，Field Size 也是一個因素。在同樣 File Size 底下，Field Size = 16 bits 會比 Field Size = 32 bits 所得到的 k 還要高，因此我們推測 Field Size = 32 bits 的. 38.

(47) 時間成本會相較來的低。然而，受限於 Matlab 內建函式庫的影響，對於有限域(GF 域)的運算只支援到 16 bits，對於需要利用到有限域的 RS Code 與 LC Code 來說是一個無法突破的點，除非自行撰寫支援 32-bit 的有限域函式。因此在本章節我們利用 32-bit 的 LT Code 來測量它的時間成本。圖 4-12 與圖 4-13 為測量結果；Chunk Size 固定為 1024 bits，X 軸為 File Size，Y 軸為花費時間，從兩張圖皆可觀測出 32-bit 的 LT Code 在編碼與解碼方面的時間成本皆優於 16-bit 的 LT Code，因此我們可以合理的推測出 Field Size 的擴增是可以降低時間成本的。. 圖 4-12 32-bit LT Code 編碼所需時間比較. 39.

(48) 圖 4-13 32-bit LT Code 解碼所需時間比較. 4.4. 安全性分析 4.4 中我們已對系統本身在空間與時間上的效能做出評估，在本章節將會進一步對系統的安全性進行分析，檔案本身在未加密的情況下的安全性、或是某些檔案內容較容易遭到破解等問題。. 4.4.1. Key Blocks組合數對安全性的影響在前文所提到系統架構中，假設一個 Chunk 包含 k 塊 Input Symbols，則 Key Manager 將以(k-1)份 Encoding Symbols 做為 Public Blocks，剩下的一份為 Key Blocks。然而這一塊 Key Blocks，就破解難度而言並不高。由於系統在運算時都是於有限域內，若破解者任意產生一組數據當作偽造的編碼區塊，則只要注意係數 wm 的部份不要與(k-1)份的 Public Blocks 相同，接下來就只要猜測 wm 的部份，最多只要猜測 216 可能性就能破解出答案，假設破解者能夠取得 Chunk 的 40.

(49) Public Blocks 部分，則破解難度相當低。為了彌補這個缺點，系統修正為(k-m)份 Public Blocks，相當於 Key Blocks 為 m 份，如此一來利用猜測來破解 Chunk 的難度就變高了，圖 4-14 m 與破解所需嘗試組合數的關係圖的 Chunk Size 固定為 1024 bits，X 軸為 m 的數目，Y 軸為破解 Chunk 需要嘗試的組合數(10n 種)。從圖中可以看出破解難度隨著 m 的增加而呈線性成長，除此之外破解難度也會因為 Field Size 的不同而提升，在圖中的兩條曲線分別代表 Field Size = 16 bits 與 Field Size = 32 bits，以傳統非對稱 RSA 加密演算法來說，可靠的金鑰長度為 1024 bits，換算成 Key Blocks 則至少需 m=64(Field Size = 16 bits 時)或 m=32(Field Size = 32 bits 時)，但這樣就相當於 Key Blocks 佔了整個 Chunk 的 100%，並不符合實際。一般來說我們能接受 Key Blocks 在整個 Chunk 中佔的比例在 20%以下，因此當 k=64 時，m=12，金鑰長度為 192 bits，比 RSA 少了 832 bits，在安全性上遜色不少，雖然可利用增加 Chunk Size 的方法來提高金鑰長度，但其中所帶來的額外時間與空間成本仍須衡量。. 圖 4-14 m 與破解所需嘗試組合數的關係圖. 41.

(50) 另一方面，提升 m 雖然可增加安全性，但 m 的提升代表 Key Blocks 在 Chunk 中佔的比例也越大，這也表示 Key Manager 需要傳送更多的資料給接收方，或者使用者必須儲存更多資料在自己的隨身儲存裝置，因此如何拿捏 m 的數目也是本系統的議題之一。. 4.4.2. Key Blocks外洩造成的影響上一節已知 m 的數目會影響到 Key Blocks 遭破解的難度，而安全性也會隨之提昇，但如果只是單純的提高 m，安全性未必就會一直提高。舉例來說，如果有心人士刻意蒐集不同的 Key Blocks，若蒐集份數達到復原檔案的門檻(k 塊)，那麼他就有可能成功竊取檔案，這正好與 404.4.1 的議題形成一個 tradeoff，因此為了衡量一個適當的 m 值，必須顯示出這兩者之間的取捨。圖 4-15 m 對於安全性的影響(Field Size = 16 bits)是基於圖 Field Size = 16. 圖 4-15 m 對於安全性的影響(Field Size = 16 bits) bits 的資料再加上另一條曲線，代表了 m 與需要蒐集的 Key Blocks 數目之間的 42.

(51) 關係，隨著 m 的提高，將會大幅降低需要蒐集的 Key Blocks 數目，畢竟如果 Key Blocks 在 Chunk 中的比例佔越大，就代表只要蒐集越少的金鑰就能達到復原門檻，而從圖中可以觀察到兩條曲線之間的平衡點約在 m=8 的地方。由於 16-bit 與 32-bit 會影響到 k 的大小，因此必須分開討論。圖 4-16 m 對於安全性的影響(Field Size = 32 bits)為 Field Size = 32 bits 的情況，此處兩條曲線的交會約在 m=7 的地方。由這兩張圖可以得知雖然 16-bit 與 32-bit 得到的 k 不同，但基本上適當的 m 值都差不多。. 圖 4-16 m 對於安全性的影響(Field Size = 32 bits). 4.4.3. Chunk Size對安全性的影響 4.4.1 與 4.4.2 我們針對 Key Blocks 的安全性以及探討 m 的適合值，然而除了 m 以外，Chunk Size 也同樣會影響 Key Blocks 的安全性。在 4.4.2 已舉出若 Key Blocks 遭攻擊者蒐集至復原門檻，則該 Chunk 有遭破解的可能性，因此 m 的提高帶來了好處與壞處，但假設 m 為定值，提高 Chunk Size. 43.

(52) 會令 k 也一同增加，同時提高復原門檻達到增加安全性的效果。圖 4-17 Chunk Size 對於安全性的影響顯示了 Chunk Size 的增加對安全性的影響；X 軸為 Chunk Size，Y 軸為破解此 Chunk 所需要蒐集的 Key Blocks 份數，固定因素為 m = 8(16-bit)與 m = 7(32-bit)，從圖中可以看到安全性隨著 Chunk Size 的提高而線性成長，雖然 Field Size = 32 bits 的曲線因為 k 較小的原因故成長較緩，但我們依然可以知道 Chunk Size 的提高對安全性是有幫助的。然而，Chunk Size 的提升會讓時間與空間成本一齊上升，速度最慢的 LC Code 在 Chunk Size = 1024 bits 與 8192bits 上甚至差了七、八倍左右，反觀 LT Code 便上升的不是那麼明顯。. 圖 4-17 Chunk Size 對於安全性的影響. 4.4.4. 檔案中的特殊Chunk造成的影響利用本系統對檔案進行編碼前會先將檔案切成許多 Chunk，每個 Chunk 都代表了一部分的檔案內容，然而有時會因為某些檔案內容的特性，導致安全性 44.

(53) 受到影響，本章節會討論那些特殊檔案內容所造成的情況與因應對策。 1) Zero Chunk：某些檔案內容可能有一部分皆為 0，因此在切成 Chunk 時會產生內容全部是 0 的 Chunk，當 Zero Chunk 出現時不管利用何種 Erasure Code 所產生的 Encoding Symbols 皆為 0，使得 Chunk 內容非常容易被推測出來；若要改善這點可以先對檔案內容進行 Hash，如此一來便可避免 Zero Chunk 的產生。 2) Constant Chunk：與 Zero Chunk 類似，但其內容皆為一致的常數，利用 Constant Chunk 產生的 Encoding Symbols 與 Zero Chunk 相較起來雖然比較不容易發覺，但如果利用的是 LT Code 則一目了然(產生 Symbols 皆為 0)；改善方法依然可以先利用 Hash Function 來避免產生。. 4.5. 三種Erasure Code的比較與適用狀況在看過 RS Code、LC Code，以及 LT Code 三種 Erasure Code 的編碼、解碼方法之後，我們可以得知它們各有不同的特性與優缺點，而根據這些差異性，應用在本系統也會有不同的影響，這讓系統可以針對不同狀況而採取不同的編碼方式，提高系統的彈性。下表整理了這三種 Erasure Code 的類型與優缺點，本章節將會藉由這些優缺點來說明它們適用的狀況。方法. 類型. 編碼方式. 時間成本. 空間成本. RS Code. Optimal. Fixed-Length. 較少. 1× k '× p (最少). LC Code. Optimal. Fountain. 最多. k × k '× p (最多). LT Code. Near-Optimal. Fountain. 最少. k × k '×1 (較少). RS Code 屬於 Optimal Erasure Code，而 Fix-Rate 代表編碼前便要決定展開塊數，這使得 k 塊展開成 n 塊之後，只有這 n 塊能進行還原程序，由於這些 Encoding Symbols 具有這種獨特性，因此 RS Code 利於用在個人儲存服務上，使用者能任意指派可用的金鑰數目，以及它們的存放位置。至於加密的檔案對象則建議在 1MB 以下(例如 Word 檔、TXT 檔等)，Chunk Size 為 1024 bits, Field Size 為 16bits，如此一來編碼所花時間約 1 分鐘，解碼約 20 分鐘。 LC Code 屬於 Optimal Erasure Code，具有 Fountain 的特性使其在分享給多人時相當便利，並且能夠產生的 Encoding Symbols 組合數在三種 Erasure Code 45.

(54) 中最多，可解碼性(Independency)為最高，但缺點在於時間與空間成本太高，因此檔案對象建議低於 100KB(如 TXT 檔)，Chunk Size 為 1024 bits, Field Size 為 16bits，從實驗數據來看編碼所花時間約 10 秒，解碼約 10 分鐘。 LT Code 屬於 Near-Optimal Erasure Code，同樣具有 Fountain 的特性，因此適合在分享檔案給多人時使用，LT Code 最大優點在於時間所耗成本相當低，因此可用在 10MB 以上的檔案(如音樂、影像檔)，當檔案大小 10MB，Chunk Size = 1024 bits，Field Size = 32 bits 時編碼所花時間約 2 分鐘，解碼約 9 分鐘。另外 LT Code 的低時間成本消耗也使得它能夠藉著提高 Chunk Size 的增加安全性，不過每增加一倍的 Chunk Size 解碼時間也約增加一倍，可依使用者的需求來調整。至於 LT Code 時間不甚穩定的缺點可依靠改良 Degree Distribution Function 或是使用 Raptor Code 來改善。. 46.