sqlite3与wxsqlite3与sqlcipher的选择

怎么也没想到会跟sqlite3折腾上三天之久。先是考虑node binding的sqlite3模块,很容易通过npm就能找到,很成熟的东西,编译通过,使用很happy.

接着要考虑对数据的加密,自然就找到了wxsqlite3和sqlcipher。众所周知,sqlite3是开源的,而且官方模块其实是有加密功能的,甚至连加密接口sqlite3_rekey()和数据库使用时解密sqlite3_key()接口都是有的,只不过是收费的,据说官方加密功能售价为2000美元。这应该就是所谓的price gouging,搞不起,搞不起。

遭遇wxsqlite3

先说说wxsqlite3,看文档功能挺强大的,而且据说QT里的sqlite3加密用的是它。它的源码里有个sqlite3secure子模块是用来实现加密功能的,它实现了四种便捷的加密级别:

  1. CODEC_TYPE_AES128
  2. CODEC_TYPE_AES256
  3. CODEC_TYPE_CHACHA20
  4. CODEC_TYPE_SQLCIPHER

可以通过函数来指定哪种加密方式:

wxsqlite3_config(db, "default:cipher", CODEC_TYPE_SQLCIPHER);

不指定的话,默认是第三种,即:ChaCha20 - Poly1305 HMAC。据说这种是新的标准,相比于AES,ChaCha20的优势在于大量基于XOR操作,就算是普通CPU也会执行得很快,而AES依赖于特定CPU指令,否则性能上会有问题。

我的理解是,第四种,即:AES 256 Bit CBC - SHA1/SHA256/SHA512 HMAC,就是sqlcipher一样的功能,也是sqlcipher采用一样的算法。

考虑到所使用的DB Browser for SQLite工具是基于SQLCipher Version 4.1.0 community (based on SQLite 3.27.2),所以就不用默认选择,而选择CODEC_TYPE_SQLCIPHER了。

添加加密模块是需要基于sqlite3源码去做修改的,sqlite3_rekey()过程其实是一个把所有数据导出再导入,每个page都单独加密的过程,加密之后文件自然会比原数据文件大那么一点点,实测我110MB的数据,加密之后也就变成了114MB左右而已。wxsqlite3提供了一个rekeyvacuum.sh脚本用来处理sqlite3.c源码,看起来一切都很顺利,wxsqlite3这货内置各种算法的源码,所以编译也没有外部依赖,感觉挺爽。

接着就各种痛苦出现了,首先是居然无法对我的数据文件进行sqlite3_rekey()操作,报错说什么『The database disk image is malformed 』,查了半天,好像也有人遇到,说是文件很大造成的,但我的数据文件只有100多M,而且DB Browser可以正常打开的。但如果通过编译了wxsqlite3功能的sqlite3,重新进行新数据库的创建和插入数据,又是可以正常加密和解密了,这就诡异了。同时又出现了另一个问题,CODEC_TYPE_SQLCIPHER方式加密的数据,无法在DB Browser里解密出来,反之也不行,可见它至少并不兼容sqlcipher的算法。

遭遇SQLCipher

查了好久,实在是无解,又开始转向sqlcipher,但过程也是相当的折腾。sqlcipher使用上会有些优势,不需要进行加密和解密接口的node封装,可以直接使用PRAGMA命令:

PRAGMA key = 'passphrase'; -- start with the existing database passphrase
PRAGMA rekey = 'new-passphrase'; -- rekey will reencrypt with the new passphrase

sqlcipher是在configure时,帮你生成好修改之后的sqlite3.c文件:

./configure --enable-tempstore=yes CFLAGS="-DSQLITE_HAS_CODEC"

但这货是基于tclsh的脚本,于是还得安装个tclsh。windows上安装麻烦,又折腾到到Linux上安装,configure完之后,再把sqlite3.c拷贝到windows里进行vs2015工程的编译。

接着是,这货完全依赖于外部的各种摘要算法,可以定义SQLCIPHER_CRYPTO_CC,或者是SQLCIPHER_CRYPTO_LIBTOMCRYPT,或者是SQLCIPHER_CRYPTO_OPENSSL. 我自然选择openssl,这时就麻烦了,因为是针对于windows的vs2015平台,所以我还得找个vs2015对应的openssl工程编译出来链接库。好不容易编译通过了,又发现动态链接库没有,哪个链接库没有,通过下面这个命令可以在windows上查看到:

dumpbin /dependents C:\xxx\sqlite3.node

显示动态链接了libcryptoMD.dll,但我希望是静态链接,于是又查找怎么在编译时指定为静态链接编译,原来是要把/MD改成/MT。又接着各种函数找不到,加上Ws2_32.lib和crypt32.lib之后,终于消停了。

接着麻烦又来了,号称是所谓的5-15% overhead,但实际测试发现,随便一个查询,至少比原来要慢三倍。一个频繁查询在sqlite3里耗时50ms,现在变成了160ms+。网上很多人也遇到同样问题,说是可以通过新建索引来减少对磁盘数据的读取,或者通过调大page的size,page的 size默认为4096,每个page为块单独加密和解密,如果读取磁盘越少,意味着需要解密次数越少,执行速度也就越快。再就是所谓的关闭一些安全检查可以提高速度,如:

PRAGMA cipher_memory_security = OFF

然而实验证明并无卵用,但无论如何,也无法接受成倍的性能消耗,于是继续折腾。还好我的需求是数据只读,不需要写入,于是可以通过在软件加载时把所有数据解密后拷贝一份到内存里,这样就能保证安全的同时不损失速度,只是启动会慢一点点,而且内存消耗会多个上百MB,正好发现SQLCipher提供了类似操作,即sqlcipher_export。不过,由于不是所有数据都对耗时敏感,所以我可以做得更好,只将数据库中使用频繁的表拷贝到内存中的临时库里,不频繁使用的就不拷贝,这样启动也不慢了,内存消耗也不大了,堪称完美。于是自己对源码进行了改写,使用起来就是:

await exec("ATTACH DATABASE ':memory:' AS tmp KEY ''")
await exec("SELECT sqlcipher_export('tmp', 'main', 'table_xxx,table_yyy')")

再接着又一问题,发现打包之后,软件比原来大了近一百M啊,原来加密之后的数据,基本成了一堆随机的二进制了,压缩算法基本就丧失了意义。这个看来无解,只能忍了。

发表于 11月21日 21:42   评论:0   阅读:142  



回到顶部

首页 | 关于我 | 关于本站 | 站内留言 | rss
python logo   django logo   tornado logo