ECC演算法分析–我們國家的標準

瞭解了前面說的ecc的概念之後，我們就知道group的意義了，實際上group定義了一條曲線，定義了a，b，還有order等等，在openssl的實現中，group中還有一個EC_METHOD結構體，這個結構體中有一系列的函數，顧名思義這些函數是用來操作曲線的，可以看到這個method沒有engine的支援，這是為什麼呢？因為ecc的創立者根本就不把ecc演算法所應用的曲線作為演算法的一部分來考慮，也就是說，這些曲線是公開的，一旦你確定了曲線的參數，那麼接下來的對曲線的操作就是確定的，沒有必要自訂實現，因此，EC_METHOD基本都是固定的，沒有engine的支援，可以說group和ecc密鑰的計算基本沒有關係，它只是提供了一個所謂的“基礎設施”，因為現代電腦並沒有實現曲線域的計演算法則，所以openssl就應該自己實現，這個實現就是group中的EC_METHOD。
      但是我們國家總是喜歡搞zg特色，正如我們國家搞雙認證體系一樣，我們國家的雙認證體係為的是方便官方取證，這在別的國家是不存在的，在別的國家，你的私密金鑰是任何機構都無權查看的，可是...公正乎？哀哉！正是因為我們的ecc標準沒有公布橢圓曲線參數，於是我們就不能使用openssl了，但是openssl實在太棒了，我無法捨棄它，於是就要想辦法將openssl改造成支援國家密碼局的ecc標準的架構。要做到這個，首先的想法就是讓EC_METHO支援engine，由於國家不公布橢圓曲線標準，那麼我們只好調用國家的介面來自己實現。怎麼讓EC_METHOD支援engine呢？很簡單，首先將自己的engine註冊進openssl，然後修改擷取group的代碼，如果需要處理的密鑰的oid是我們國家的標準，那麼就擷取我們實現的engine，之後就用我們的engine的實現的方法來實現曲線操作。
     實現了曲線操作，接下來的密鑰操作就簡單了，密鑰操作都是在“曲線”上進行的，只要我們載入自己的engine，那麼很容易就可以使得我們自己的engine得到使用，這個就不必多說了，詳細情況請看關於engine的介紹。這個工作簡單的原因在於ecdh或者ecdsa等本來就是支援engine的。為了實現國密的ecc演算法，或者說將國密ecc整合進openssl，我們需要很多的工作要做，我們之所以值得做這些工作原因有二：第一，國家的標準我們必須實現；第二，openssl實在太棒了！