魏 榮, 鄭昉昱, 林璟鏘

1. 中國科學(xué)院 信息工程研究所 信息安全國家重點實驗室, 北京100093

2. 中國科學(xué)院 數(shù)據(jù)與通信保護(hù)研究教育中心, 北京100093

3. 中國科學(xué)院大學(xué) 網(wǎng)絡(luò)空間安全學(xué)院, 北京100049

4. 中國科學(xué)技術(shù)大學(xué) 網(wǎng)絡(luò)空間安全學(xué)院, 合肥230026

1 引言

Web 應(yīng)用是指以B/S (瀏覽器/服務(wù)器, Browser/Server) 模式提供服務(wù)的網(wǎng)絡(luò)程序, 相對C/S (客戶端/服務(wù)器, Client/Server) 架構(gòu)的傳統(tǒng)桌面應(yīng)用而言, 其具有跨平臺、兼容性好、維護(hù)成本低、免安裝的優(yōu)勢, 因而在近年來迅猛發(fā)展, 甚至曾一度出現(xiàn)了Web 應(yīng)用取代桌面應(yīng)用的呼聲.

當(dāng)然, 在未來相當(dāng)長的一段時期內(nèi), Web 應(yīng)用都難以完全淘汰桌面應(yīng)用, 因為它受到了本地資源訪問限制、網(wǎng)絡(luò)設(shè)施建設(shè)等因素的影響, 除了在功能豐富度方面無法與桌面程序比擬外, 其響應(yīng)速度也極度依賴網(wǎng)絡(luò)性能, 常出現(xiàn)內(nèi)容加載緩慢等問題, 而最致命的還是Web 技術(shù)在實現(xiàn)密碼運算時天然存在的短板:

(1) Web 應(yīng)用的鑒權(quán)過程往往需要將用戶口令發(fā)送到服務(wù)端進(jìn)行比對, 盡管客戶端會使用加鹽哈希來予以一定保護(hù), 但仍不能徹底解決竊聽、重放等問題;

(2) 雖然一些口令身份鑒別機制可以讓W(xué)eb 應(yīng)用不用發(fā)送口令信息就能完成密鑰協(xié)商, 例如EKE(Encrypted Key Exchange)[1]、J-PAKE (Password-Authenticated Key Exchange by Juggling)[2]等, 但需要客戶端能夠完成較為復(fù)雜的密碼運算——如果以瀏覽器密碼插件的形式實現(xiàn), 則要求插件程序兼容各個系統(tǒng)平臺和瀏覽器內(nèi)核, 維護(hù)成本較高; 而如果讓JavaScript 來完成這部分工作, 則要求瀏覽器內(nèi)核對JavaScript 的解釋速度足夠快, 以免影響用戶體驗;

(3) 雖然瀏覽器都內(nèi)置了HTTPS (Hyper Text Transfer Protocol over Secure Socket Layer, 超文本傳輸安全協(xié)議) 功能, 但該功能只提供統(tǒng)一的認(rèn)證、加密和完整性保護(hù)服務(wù), 開發(fā)者無法利用其內(nèi)置的密碼算法來實現(xiàn)自定義的安全協(xié)議.

不難看出, 讓JavaScript 承擔(dān)密碼運算工作是Web 應(yīng)用發(fā)展的大勢所趨, 由于終端設(shè)備和瀏覽器多種多樣, 性能良莠不齊, 難免有人擔(dān)心作為腳本語言的JavaScript 無法勝任復(fù)雜運算工作(如橢圓曲線標(biāo)量乘). 不過, 隨著近年來計算機硬件性能大幅度提升和瀏覽器內(nèi)核更新?lián)Q代, JavaScript 的執(zhí)行速度已經(jīng)有了很大改觀, 可以勝任復(fù)雜密碼運算的工作, 尤其是移動互聯(lián)網(wǎng)時代的到來和HTML5[3](HyperText Markup Language 5, 超文本標(biāo)記語言5) 技術(shù)的發(fā)展, 使得Web 應(yīng)用在智能移動終端中也大放異彩. 讓前端腳本承擔(dān)更多力所能及的計算工作已然時機成熟.

而在我國, 由于計算機硬件、操作系統(tǒng)和軟件設(shè)施建設(shè)長期落后國際水平, 導(dǎo)致缺乏基本的國產(chǎn)化軟硬件平臺, 國產(chǎn)密碼推進(jìn)工作遲滯. 雖然SM2[4-8]、SM3[9]和SM9[10-14]算法已經(jīng)上升為國際標(biāo)準(zhǔn), 但要得到主流瀏覽器內(nèi)核的支持, 還有相當(dāng)長的路要走. 目前也只有360[15]、密信[16]、贏達(dá)信[17]等個別企業(yè)推出了支持國密算法的瀏覽器產(chǎn)品, 其普及度還很低, 而國內(nèi)為數(shù)眾多的Web 應(yīng)用都還在使用國外密碼算法來保障數(shù)據(jù)安全, 其中不乏MD5、SHA-1、DES、RSA-1024 等已經(jīng)被建議淘汰或明令禁止的不安全算法.

值得高興的是, 使用JavaScript 實現(xiàn)密碼算法不必拘泥于軟硬件平臺的限制, 這意味著我們可以方便地使用國產(chǎn)密碼算法, 不用考慮瀏覽器是否支持的問題.

2 研究問題與現(xiàn)狀

我們旨在用JavaScript 實現(xiàn)一款適用于Web 應(yīng)用的通用密碼庫, 可以提供國密SM2、SM3 和SM4[18]算法, 并保證該庫壓縮后的大小控制在50 KB 以內(nèi).

在Web 應(yīng)用中, JavaScript 的性能體現(xiàn)在加載速度和執(zhí)行速度兩方面, 而這兩者往往處于對立關(guān)系. 例如, AES (Advanced Encryption Standard, 高級加密標(biāo)準(zhǔn)) 算法在OpenSSL 中的實現(xiàn)采用了TTable[19]和循環(huán)展開的技巧, 前者將狀態(tài)矩陣每一列的列混淆和字節(jié)代替操作融合在一張1 KB 大小的查找表中, 只需一次訪存就可以完成上述變換, 還可以省略行移位步驟, 但該方法需要加密和解密函數(shù)各自維護(hù)4 KB 大小的查找表, 這在本地應(yīng)用中并不算很大的存儲負(fù)載, 不過在Web 應(yīng)用中, 從服務(wù)端下載8 KB 的查找表會明顯增加網(wǎng)絡(luò)延遲; 循環(huán)展開方式也存在類似問題, 以AES-128 為例, 如果將循環(huán)展開,則會導(dǎo)致主函數(shù)代碼量增加近十倍, 同樣會顯著增加網(wǎng)絡(luò)延遲. 因此, 在實現(xiàn)算法時, 應(yīng)權(quán)衡代碼量和執(zhí)行速度之間的利害取舍, 對可以通過少許代碼預(yù)計算出來的常量, 盡量延后到本地生成, 以減小流量消耗, 但也要注意, 預(yù)計算的時間開銷不宜過長.

當(dāng)然, 針對JavaScript 難以進(jìn)行高性能計算的問題, 最理想的解決方案還是盡可能利用設(shè)備本地的資源和計算能力, 這樣不僅可以避免重復(fù)下載密碼庫, 還可以省去腳本解釋執(zhí)行的漫長過程, 在Web 技術(shù)的發(fā)展過程中, 也確實產(chǎn)生了很多相關(guān)的支撐技術(shù), 例如現(xiàn)代瀏覽器普遍支持的JIT (Just In Time,即時) 編譯技術(shù)[20]大大彌補了JavaScript 作為腳本語言的天然速度劣勢; 此外, 還出現(xiàn)了WebGL[21]、WebAssembly[22]、和asm.js[23]等更深程度的優(yōu)化執(zhí)行技術(shù), 它們力求讓JavaScript 的運行速度能夠媲美Native 代碼, 然而, 除了瀏覽器支持程度不理想外, 其較大的編譯輸出會嚴(yán)重增加下載時間; 隨著HTML5 技術(shù)的發(fā)展, 一些主流瀏覽器也加入了對Web Worker[24]的支持, 從而改變了長期以來JavaScript 只能單線程執(zhí)行的狀況, 讓W(xué)eb 應(yīng)用也開始步入并行計算的時代.

上述各種技術(shù)的演進(jìn)都是以提升用戶體驗為導(dǎo)向的, 其優(yōu)先考慮的是頁面渲染和響應(yīng)速度, 而非數(shù)據(jù)安全問題, 密碼庫的開發(fā)者可以對其加以利用, 以提高密碼計算效率, 但敏感數(shù)據(jù)的安全暫時還要靠瀏覽器的隔離機制來保證.

考慮到瀏覽器中的數(shù)據(jù)安全問題, W3C (World Wide Web Consortium, 萬維網(wǎng)聯(lián)盟) 于2017 年正式提出了關(guān)于Web Cryptography API[25]的建議, 期望能夠以JavaScript 接口形式為Web 應(yīng)用提供基礎(chǔ)的密碼服務(wù), 各主流瀏覽器也開始加入對上述接口的實現(xiàn). 由于處于更底層位置, 這類密碼服務(wù)的性能遠(yuǎn)比第三方JavaScript 密碼庫更接近Native 代碼[26], 但截至目前, 不同瀏覽器所實現(xiàn)的算法集合或多或少都存在差別, 只有極個別瀏覽器(如Samsung Internet[27]) 完整實現(xiàn)了所有API[28]. 因此, 在未來很長一段時期內(nèi), Web 開發(fā)者依然需要集成自己的JavaScript 密碼庫以備不時之需.

可見, 即便是應(yīng)用廣泛的國際算法, 也未能如HTTPS 一般成為瀏覽器的標(biāo)配功能, 而在國外廠商占據(jù)主流瀏覽器市場的今天, 國產(chǎn)密碼算法要得到瀏覽器的集成則更是任重道遠(yuǎn). 2017 年, 中科院DCS 中心研制了通過Windows CNG[29]接口提供服務(wù)的國產(chǎn)商用密碼算法庫, 并基于該庫研制了支持商密算法的Edge 瀏覽器和IE 瀏覽器[30], 上述兩款瀏覽器利用了操作系統(tǒng)的密碼服務(wù)來為Web 程序提供更安全的密碼功能, 這也是未來Web 密碼服務(wù)形態(tài)的一大發(fā)展方向——Web 應(yīng)用中的密碼服務(wù)最終是要沉降到更為快速和安全的瀏覽器內(nèi)核甚至操作系統(tǒng)中來實現(xiàn)的. 但與前文所述的技術(shù)類似, 上述產(chǎn)品也僅僅提供了基于Windows 10 系統(tǒng)上兩種瀏覽器的密碼服務(wù), 并不具備普適性, 鑒于我國在操作系統(tǒng)和瀏覽器領(lǐng)域長期落后的現(xiàn)狀, JavaScript 庫仍將是國產(chǎn)密碼算法入駐瀏覽器的主要形態(tài).

3 實現(xiàn)方案

本節(jié)主要闡述JavaScript 庫中對國密算法的實現(xiàn)和優(yōu)化方案, 并不介紹原算法過程, 讀者如果想了解算法原理, 可以查閱相關(guān)國密標(biāo)準(zhǔn)[4-8,18,31].

3.1 實現(xiàn)思路

目前已經(jīng)有很多較為著名的JavaScript 國際密碼算法庫, 如clipperz[32]、OpenPGP.js[33]、sjcl[34]、jwcrypto[35]、cryptico[36]、jscrypto[37]和cryptojs[38]等. 綜合考慮文件大小、代碼架構(gòu)、密碼算法集合和優(yōu)化程度, 我們決定基于sjcl 庫完成對國產(chǎn)密碼算法的集成和優(yōu)化.

sjcl 是由斯坦福大學(xué)Stark 等于2009 年推出的一款適用于瀏覽器和Node JS 平臺的JavaScript 密碼庫, 該庫最初圍繞AES 算法進(jìn)行優(yōu)化實現(xiàn), 隨著版本演進(jìn), 目前已經(jīng)能夠支持國際上常用的對稱、非對稱密碼算法、哈希算法、消息認(rèn)證函數(shù)、KDF (Key Derivation Function, 密鑰派生函數(shù)) 以及隨機數(shù)發(fā)生函數(shù), 成為了一款比較全面的密碼套件, 該庫還針對腳本加載速度進(jìn)行了一定程度的優(yōu)化, 以提升用戶體驗.

相比上文中其他較流行的密碼庫, sjcl 重點關(guān)注密碼原語的優(yōu)化實現(xiàn), 而非更高層的通信或密碼協(xié)議,因此非常精簡, 具有更小的體量和更好的兼容性, 這不僅體現(xiàn)在平臺兼容性上(它通過了Mac、Linux 和Windows 系統(tǒng)下所有主流瀏覽器的測試), 還體現(xiàn)在對舊的ES5[39](ECMAScript 5) 標(biāo)準(zhǔn)的完美兼容上.

更重要的是, sjcl 庫的模塊化代碼結(jié)構(gòu)對二次開發(fā)非常友好, 各個模塊之間的松散耦合便于開發(fā)者根據(jù)實際需要選擇性地打包, 隨時去除不必要的功能, 這有利于縮減文件大小, 同時也讓該庫具備了很好的可擴(kuò)展性, 新算法的集成工作比其他同類庫更為方便. 此外, sjcl 庫一直致力于針對Web 應(yīng)用場景對密碼算法進(jìn)行特殊優(yōu)化[34], 相比同類密碼庫, 它在文件大小和運算速度之間達(dá)到了較好的平衡[26].

我們基于sjcl 密碼庫的框架, 用JavaScript 實現(xiàn)了SM2 簽名和加密算法、SM3 摘要算法和SM4 對稱加密算法, 支持瀏覽器和Node JS 平臺, 接口與sjcl 庫保持了風(fēng)格一致, 繼承了其調(diào)用簡單的優(yōu)點; 與此同時, 針對最為耗時的ECC (Elliptic Curves Cryptography, 橢圓曲線密碼學(xué)) 算法, 我們也進(jìn)行了一定程度的優(yōu)化, 將ECC 密鑰生成和簽名速度提升了一倍.

3.2 對SM2 算法的優(yōu)化

由于sjcl 庫代碼架構(gòu)的原因, 對SM2 算法的優(yōu)化實際上也可以惠及庫中其他ECC 算法.

對ECC 橢圓曲線算法的優(yōu)化通常集中在最為耗時的點乘運算上, sjcl 庫用了常見的固定基窗口方式[40]來加速點乘, 但沒有對乘法標(biāo)量進(jìn)行長度擴(kuò)充, 使其與橢圓曲線基點的階等長, 容易在時序分析下暴露乘法標(biāo)量(如私鑰) 長度信息, 當(dāng)然, 這只是一個小問題, 我們對其進(jìn)行了修復(fù).

考慮到內(nèi)存占用和預(yù)計算的時間開銷, sjcl 庫所選的窗口寬度為4. 例如, 對256 位長的標(biāo)量乘數(shù)t 和點P, 通過64 次“訪存-16 倍點-點加” 操作來完成[t]P 運算, 步驟如下:

(1) 將t 表示為16 進(jìn)制:

(2) 計算所有Pk=[k]P, 其中k =0,1,··· ,15;

(3) 按公式(1)計算[t]P:

還有一種固定基的comb 方法[9], 以另外一種形式來分割乘法標(biāo)量, 通過64 次“訪存-2 倍點-點加”操作來計算[t]P, 但是乘法標(biāo)量的預(yù)處理和查找表的預(yù)計算也相對更繁瑣一些. 以模長l = 256, 窗口寬w =4 為例, 使用固定基comb 方法計算[t]P 的步驟如下:

(1) 將t 表示為二進(jìn)制, 并均分為4 部分:

(2) 計算所有[2192s3+2128s2+264s1+s0]P, 記作Pk, k =s3|s2|s1|s0, s0、s1、s2和s3為0 或1;

(3) 按公式(2)計算[t]P:

與窗口方法不同, comb 方法的預(yù)計算無法只通過點加和倍點完成, 需要調(diào)用點乘方法, 因而不能在點乘運行時進(jìn)行. 該方法更適合將預(yù)計算結(jié)果直接硬編碼在程序中, 但這種做法與sjcl 庫精簡代碼、降低下載流量的設(shè)計原則不符, 加之預(yù)計算比窗口方法耗時, 最終沒有被sjcl 庫采納.

不過, 對于固定點(如橢圓曲線基點) 乘法來說, comb 方法只需在曲線初始化時進(jìn)行一次預(yù)計算即可,我們?yōu)榍€基點編寫了單獨的點乘方法, 使用comb 方法省去了75% 的倍點運算, 讓基點的點乘運算速度提升了約110%, 從而加速了ECC 密鑰生成和簽名過程. 在Maxthon 瀏覽器中, ECDSA (Elliptic Curve Digital Signature Algorithm, 橢圓曲線數(shù)字簽名算法) 和SM2 簽名算法優(yōu)化前后的性能數(shù)據(jù)如表1 所示:

表1 ECC 優(yōu)化前后性能對比Table 1 Performance with and without optimization for ECC

另外, SM2 簽名算法中, 對消息的預(yù)處理需要公鑰參與, 而每次重復(fù)計算公鑰會造成顯著的時間開銷,我們在生成和導(dǎo)入密鑰對時, 將公鑰也保存在了私鑰對象中, 以節(jié)省一次不必要的標(biāo)量乘.

在支持多線程的平臺上實現(xiàn)上述兩種優(yōu)化方法時, 如果將公式(1)和公式(2)分派給多個線程去運算,還可以獲得成倍的加速效果. 例如: 在固定基comb 方法中, 如果將i ∈[0,31] 和i ∈[32,63] 部分的累加工作分派給兩個子線程去完成, 最后在主線程中合并結(jié)果, 從理論上來講, 就可以獲得近兩倍的加速效果.

就固定基comb 方法應(yīng)該使用多少線程的問題, 我們曾用C 語言在64 位PC 平臺(4 核處理器) 和ARM 平臺(8 核處理器) 上分別測試了開啟1、2、4、8 個子線程時的SM2 點乘運算速度. 實驗表明, 在開啟4 個子線程時, 速度達(dá)到了最佳——可見, 并不是線程數(shù)越多, 并行度越高, 效率就越高, 如果線程太多, 而每個線程的計算量太小, 則線程創(chuàng)建和銷毀的開銷在運行時間中的占比也會升高, 變得不可忽略, 反而導(dǎo)致性能下降.

不幸的是, 由于瀏覽器中UI (User Interface, 用戶界面) 渲染線程和JavaScript 引擎對DOM (Document Object Model, 文檔對象模型) 樹的訪問是互斥的, 曾經(jīng)有很長一段時間, 為了保證線程安全,JavaScript 都不提供多線程機制. 雖然HTML5 提供了Web Worker 機制, 允許將不訪問DOM 的JavaScript 代碼放在后臺線程中運行, 但它要求將子線程需要用到的所有對象和函數(shù)結(jié)構(gòu)化拷貝到新的上下文環(huán)境中, 而一次這樣的拷貝往往要耗時上百毫秒, 其線程本身的開銷遠(yuǎn)遠(yuǎn)高于C 語言, 可見Web Worker 機制的主要用途在于確保執(zhí)行腳本時不阻塞頁面渲染, 而非高性能并行計算. 因此, 我們最終決定基于單線程JavaScript 來完成實現(xiàn).

3.3 關(guān)于SM3 和SM4 的實現(xiàn)

JavaScript 作為一種弱類型的腳本語言, 默認(rèn)的number 類型為64 位雙精度浮點數(shù), 相當(dāng)于C 語言中的double 類型. 但是在參與位運算時, 會默認(rèn)轉(zhuǎn)化為32 位整數(shù), 也就是說它并不支持32 位以上的長整數(shù), 這不利于實現(xiàn)高性能的密碼學(xué)大數(shù)運算, 好在SM3 和SM4 算法中的位操作所針對的至多是32 位長的字, 不會受到影響.

sjcl 庫的AES 算法實現(xiàn)采用了T-Table 優(yōu)化, 而前文也提到過, 這種方法需要維護(hù)8 KB 大小的查找表, 不宜直接使用硬編碼方式, Stark 等人將S 盒、逆向S 盒以及擴(kuò)展查找表都放在預(yù)計算階段中, 在第一次調(diào)用AES 算法時才會動態(tài)生成上述查找表, 而只存儲了硬編碼的輪常量. 需要注意的是, Web 應(yīng)用場景下, 敵手更容易獲得加密耗時, 進(jìn)而發(fā)起時序攻擊, sjcl 庫在使用T-Table 方案時, 在AES 函數(shù)首輪和末輪放棄使用T-Table 表, 轉(zhuǎn)而選擇了查找S 盒的傳統(tǒng)方式, 這可以在一定程度上防止基于緩存的時序攻擊.

與SPN (Substitution-Permutation Network, 代替-置換網(wǎng)絡(luò)) 結(jié)構(gòu)的AES 算法相比, SM4 算法則屬于非對稱Feistel 結(jié)構(gòu), 其輪函數(shù)的處理對象也迥異于AES 算法的4×4 狀態(tài)矩陣, 從理論上來看, 對SM4 使用T-Table 方案所能產(chǎn)生的優(yōu)化效果雖然遠(yuǎn)不如AES, 但在編碼時, 也理應(yīng)能在每輪處理中節(jié)省7 次位操作.

SM4 算法分組長度 16 字節(jié), 需要進(jìn)行 32 輪變換, 將第 i 輪狀態(tài)記作 4 個 32 位字:(Xi,Xi+1,Xi+2,Xi+3), 記第i 輪輪密鑰為Ki, 其中i=1,2,··· ,32, 則輪變換步驟如下:

(1) A=(a0,a1,a2,a3)=Xi+1⊕Xi+2⊕Xi+3⊕Ki;

(2) B =(b0,b1,b2,b3)=(S[a0],S[a1],S[a2],S[a3]);

(3) C =B ⊕(B ＜＜＜2)⊕(B ＜＜＜10)⊕(B ＜＜＜18)⊕(B ＜＜＜24);

(4) Xi+4=Xi⊕C.

步驟(2) 中, 符號S 表示查找S 盒. 而在T-Table 方案中, 可以將步驟(2) 和步驟(3) 合并如下:

(1) y =S[x],x=0,1,··· ,255;

(2) Ti[x]=(y ⊕(y ＜＜2),y ⊕(y ＞＞6),y ＜＜＜2,y ＜＜＜2)＞＞＞8i,i=0,1,2,3.

上述步驟(2) 就是借助SM4 的S 盒生成T-Table 查找表的方法. 我們測試了SM4 算法T-Table 方案的優(yōu)化效果, 結(jié)果很出乎意料——在JavaScript 實現(xiàn)中, 采用T-Table 的SM4 加密速度略慢于未優(yōu)化版本. 經(jīng)過實驗與分析, 我們發(fā)現(xiàn)查找T-Table 表的耗時超過了查找S 盒一倍, 可見至少在測試瀏覽器的JavaScript 解釋器下, 對32 位字的訪存所消耗的機器周期要多于對字節(jié)的訪存, 這一點與Native 代碼有著明顯差異.

除了T-Table 外, bit slicing[41]也是一種常用于對稱加密算法的優(yōu)化技巧, 可以實現(xiàn)對大規(guī)模數(shù)據(jù)的并行處理. 然而, AES 和SM4 的S 盒是基于有限域理論設(shè)計的, 在bit slicing 實現(xiàn)時會分解為大量位操作[42,43], 這意味著JavaScript 代碼量的急劇增加, 因此并不適合在Web 應(yīng)用中采用.

基于以上考慮, 我們最終采用了原始版SM4, 雖然加密輪數(shù)多于AES, 速度也比T-Table 版AES 要慢很多, 但只需維護(hù)256 B 大小的S 盒即可. 由于預(yù)計算S 盒的代碼量超過了硬編碼的大小, 直接使用硬編碼方式更為合理.

4 性能測試

由于缺乏可橫向?qū)Ρ鹊耐愅ㄓ妹艽a套件, 我們僅對擴(kuò)充后的sjcl 庫進(jìn)行了測試, 并對國密算法和參數(shù)規(guī)模與之相當(dāng)?shù)膶?yīng)國際算法進(jìn)行了性能對比.

4.1 測試環(huán)境

我們通過腳本將源代碼打包成了47 KB 的密碼庫文件, 并在64 位Windows 平臺上, 使用了三種主流瀏覽器和一款國產(chǎn)瀏覽器進(jìn)行性能測試, 測試平臺的具體型號、配置和版本如表2 和表3 所示.作為最具代表性的瀏覽器, 上述幾種平臺均在不同程度上實現(xiàn)了Web Crypto API, 但目前都不支持國產(chǎn)密碼算法.

表2 系統(tǒng)/硬件平臺Table 2 System/Hardwares

表3 軟件平臺Table 3 Softwares

4.2 測試結(jié)果

我們分別對比了ECDSA 和SM2 簽名算法、SHA-256 和SM3 哈希算法以及AES-128 和SM4 對稱加密算法的性能, 結(jié)果分別見表4、表5 和表6.

表4 ECC 簽名算法(單線程) 性能Table 4 Performance of ECC Signature Algorithms (with Single Thread)

表5 哈希算法性能(Mbps)Table 5 Performance of Hash Algorithms (Mbps)

表6 對稱加密算法性能(Mbps)Table 6 Performance of Symmetric Encryption Algorithms (Mbps)

由于我們對定點標(biāo)量乘進(jìn)行了優(yōu)化, 因此ECC 算法中涉及基點乘法運算的密鑰生成和簽名過程要比驗簽快很多.

T-Table 方法旨在節(jié)省對稱加密算法查找S 盒之后的混淆和擴(kuò)散步驟, 與S 盒類似, Feistel 結(jié)構(gòu)的算法(如DES、SM4) 加解密過程共用一套T-Table 查找表, 而AES 則不然, 并且在使用該方法對AES 算法進(jìn)行優(yōu)化時, 由于解密過程中的逆向字節(jié)代替無法融入查找表, 所以優(yōu)化程度較加密過程要低, 從表6 中可以看出, AES 算法的加密速度要高于解密速度.

Maxthon 瀏覽器實際上使用了Chrome 的webkit[44]內(nèi)核并作出了優(yōu)化, 其內(nèi)置JavaScript 引擎為Chrome V8[45], 因此二者性能都很接近使用Carakan[46]引擎的Opera 瀏覽器. 相對于Chrome 而言,FireFox 所使用的SpiderMonkey[47]引擎顯然具有更高的計算性能.

5 結(jié)論與展望

我們基于sjcl 密碼庫, 實現(xiàn)了JavaScript 版國密SM2、SM3 和SM4 算法, 形成了一款新的通用密碼套件, 可以為Web 應(yīng)用提供適度安全的前端通用密碼服務(wù). 此外, 我們使用固定基comb 方法對橢圓曲線點乘進(jìn)行了加速, 將ECC 密鑰生成和簽名的運算速度提升了一倍以上.目前存在的問題和下一步工作:

(1) 雖然實現(xiàn)了SM2 等非對稱算法, 但使用場景十分有限, 不論是安全性還是功能都無法與驅(qū)動加硬件Key 的模式相比, 目前至多可以用于J-PAKE 等協(xié)議以及加密、驗簽工作, 在未來工作中,我們將考慮利用拆分或口令派生機制, 予以私鑰更高等級的保護(hù);

(2) 目前所實現(xiàn)的SM4 算法系基礎(chǔ)版本, 在部分平臺上比sjcl 的AES-128 慢一倍左右, 我們也嘗試過利用SIMD.js[48]或bit slicing 來進(jìn)行優(yōu)化, 但沒有得出可行有效的方法, 反倒是AES-128 可以利用SIMD.js 進(jìn)行向量化實現(xiàn), SM4 可能還存在軟件優(yōu)化空間, 希望下一步工作中能夠找到有效方法來提升其性能;

(3) 在移動互聯(lián)網(wǎng)應(yīng)用中, HTML5+Native 的架構(gòu)大行其道, 它用Web 代碼來實現(xiàn)需要跨平臺的核心功能, 極大地簡化了開發(fā)工作, 還讓HTML5 可以方便地訪問移動終端Native 資源, 如傳感器、相機、通信錄等, 這在傳統(tǒng)PC 上是很難實現(xiàn)的, 因此可以很大程度上解決Web 應(yīng)用功能受限的問題, 而這也給了我們新的啟發(fā)——至少在移動端上, 能否利用對Native 的訪問來擴(kuò)展非對稱密碼算法的應(yīng)用場景, 實現(xiàn)移動軟件Key 的效果？能否利用Native 資源為移動Web 應(yīng)用構(gòu)造高質(zhì)量的隨機數(shù)發(fā)生器？我們相信這些設(shè)想都值得在下一步工作中去嘗試.