橢圓曲線可以簡單理解為定義了一個特定點的集合，例如下面這種公式定義了比較常見的一類橢圓曲線：
其中滿足公式成立的點(x, y)都在橢圓曲線上。橢圓曲線密碼透過在限定的點集上定義相關的點運算，實現加解密功能。
在橢圓曲線加解密過程中，首先面臨的問題是『如何將待加密的資料嵌入到橢圓曲線上，透過點運算來完成加密操作』。這需要將明文資料m對映到橢圓曲線上的一個特定點M(x, y)。
資料編碼方式是將明文資料m透過進位制轉換到橢圓曲線上某點的x座標值，然後計算m^3 + am + b的完全平方數，得到y，這樣就將m轉換到了點M(x, y)。
資料解碼方式比較直白，解密還原出明文資料點M之後，讀取M的x座標值，再透過進位制轉換還原為明文資訊m。
然而，密碼橢圓曲線是定義在有限域上的，即曲線上是一個離散的點集合。這樣會導致計算完全平方數不一定存在，即x沒有對應的y在橢圓曲線上，那麼，部分明文資料無法轉換到橢圓曲線上的點，從而導致部分資料無法被直接加密。
在實際工程化的方案中，為了保證橢圓曲線加解密的可用性，會加入其它更復雜的擴充編碼機制，以應對明文資料轉換失敗的情況。
一般而言，密碼學協議中所定義的型別要求越多，資料對映的工程實現也會越複雜，如果缺乏高效的資料編解碼演算法和配套的硬體最佳化支援，即便密碼學協議的理論計算複雜度再低，最終也是難以實用化。
具體的資料對映涉及到很多流程細節和演算法引數，一旦存在微小的差異，由不匹配的編碼演算法所產生的資料，都會極大概率無法解碼，導致隱私資料丟失、業務中斷。
所以，在具體工程實現時，資料對映需要嚴格按照已有工程標準的實現要求，以國密SM2為例，可以參考GM/T0009-2012《SM2密碼演算法使用規範》、GM/T0010-2012《SM2密碼演算法加密簽名訊息語法規範》等一系列相關技術標準。
2. 業務應用難題：資料太長 工程實現之道：資料分組
除了型別不匹配，密碼學協議中使用的核心演算法對輸入的資料長度往往也有一定要求。但在實際應用中，需要處理源自不同業務需求的隱私資料，難以限定其長度，難免會出現資料長度超出核心演算法處理長度的情況。
例如，對稱加密AES演算法AES-128、AES-256，表明其使用的金鑰位數分別是128位和256位，但加密過程中單次進行核心密碼運算時處理的資料固定為128位。
針對以上問題，密碼學工程實現中一般透過資料分組進行處理，即化整為零，將長資料切分為多個較短且符合長度要求的資料塊。
典型的例子是分組加密，例如AES、DES等。分組加密顧名思義就是，將輸入的資料分組為固定長度的資料塊，然後以資料塊為單位作為核心密碼演算法的處理單元進行加解密處理。
為了在資料分組之後，依舊保持方案的安全性，資料分組技術不僅僅是簡單地對資料進行劃分，還需要引入額外的流程操作。
下面以AES 256位金鑰加密為例，介紹其中典型的分組加密模式ECB、CBC和CTR。
ECB模式 (Electronic Code Book)
ECB是最簡單的分組加密模式，也是不安全分組模式的典範。
假定有1280位待加密的資料，ECB模式將其平均分為10個128位資料塊。每個資料塊使用相同的金鑰單獨加密生成塊密文，最後塊密文進行串聯生成最終的密文。
ECB模式的加密特點是在相同的明文和金鑰情況下，其密文相同，因此洩露了明文資料與密文資料之間的關聯性，不推薦用於任何隱私保護方案中。
· CBC模式 (Cipher Block Chaining)
CBC模式透過前後資料塊的資料串連避免ECB模式的缺點。
與ECB模式類似，CBC模式中，每個明文塊先與前一個密文塊進行異或後，再進行加密。在這種方法中，每個密文塊都依賴於它前面的所有明文塊。同時，為了保證每個資料密文的隨機性，在第一個塊中需要使用一個隨機的資料塊作為初始化向量IV。
CBC模式解決了ECB模式的安全問題，但也帶來了一定的效能問題。其主要缺點在於每個密文塊都依賴於前面的所有明文塊，導致加密過程是序列的，無法並行化。
· CTR模式 (CounTeR)
CTR模式的出現讓分組加密更安全且並行化，透過遞增一個加密計數器以產生連續的金鑰流，使得分組密碼變為流密碼進行加密處理，安全性更高。
CTR加密和解密過程均可以進行並行處理，使得在多處理器的硬體上實現高效能的海量隱私資料的併發處理成為了可能，這是目前最為推薦的資料分組模式。
密碼學協議中的資料分組與傳統大資料處理中的資料分組有很大區別。理想情況下，資料分組不應該弱化隱私保護的強度，不能為攻擊者獲取未授權的資訊提供可乘之機。這往往會涉及精心的資料分組方案設計，不能簡單看作是資料分塊之後的批處理。
3. 業務應用難題：資料太短 工程實現之道：資料填充
資料太長是個問題，資料太短往往也是問題。
在以上分組處理的過程中，最後一個資料塊中資料長度不足，密碼學協議中的核心演算法也可能無法工作。
假定一個密碼協議處理的資料塊長度要求為6位元組，待加密的隱私資料長度為7位元組。用兩個十六進位制數代表一個位元組資料，其示例如下：
b1 b2 b3 b4 b5 b6 b7
7位元組長於資料塊的處理長度6位元組，因此該資料將被分組，且可以分為兩個資料塊。分組示例如下：
第一個資料塊：b1 b2 b3 b4 b5 b6
第二個資料塊：b7
其中第一個資料塊剛好是6個字元，第二個資料塊只有1個位元組，這個資料塊就太短了，不滿足處理要求。
針對以上問題，密碼學工程實現中一般透過資料填充進行處理，即將短的資料塊填充補位到要求的位元組長度。示例中第二個資料塊需要進行資料填充，為其補上缺少的5個位元組。
與資料分組類似，這裡的資料填充也不是普通的資料填充，也應該滿足一定的安全性要求。最常用的資料填充標準是PKCS#7，也是OpenSSL協議預設採用的資料填充模式。
· PKCS#7填充
需要填充的部分都記錄填充的總位元組數。應用於示例中第二個資料塊，則補5個位元組都是5的資料，其填充效果如下：
b7 05 05 05 05 05
這裡還存在一個問題：如果一個隱私資料的最後一個分組，剛好就是一個符合其填充規則的資料，在事後提取原始資料時，如何分辨是原始資料還是填充之後的資料？
避開這種歧義情況的關鍵是，任何長度的原始資料，在最後一個資料塊中，都要求進行資料填充。
值得注意的是，對隱私資料加密時，按特定填充模式進行處理，那麼填充的資料也將被加密，成為加密前明文資料的一部分。解密時，其填充模式也需要和加密時的填充模式相同，這樣才可以正確地剔除填充資料，提取出正確的隱私資料。
在隱私保護方案的編解碼過程中，以上提到的資料對映、資料分組、資料填充，都是保證隱私資料安全的必要環節。此外，在特定的合規要求下，實際業務系統還需要引入更多的相關資料預處理環節，如資料脫敏、資料認證等，使得資料在進入密碼學協議前，儘早降低潛在的隱私風險。
正是：理論公式抽象賽天書，工程編碼巧手點迷津！
學術論文的公式符號與隱私保護方案的可用工程實現之間，存在一條不小的技術鴻溝，而密碼學特有的資料編解碼，正是我們建立橋樑實現學術成果產業轉化的基石。
安全高效的資料編解碼技術，對於處理以5G、物聯網為爆點的海量隱私資料應用意義重大，是隱私資料進出業務系統的第一道防線，其重要性不亞於其他密碼學原語。
瞭解完資料編解碼之後，接下來將進入具體應用相關的密碼學原語，欲知詳情，敬請關注下文分解。
