簡介SQLCipher 3.0.1 Windows 版本是一套面向數(shù)據(jù)庫開發(fā)者的加密工具包基于 SQLite 提供透明加密能力適合需要在桌面應(yīng)用中集成數(shù)據(jù)庫加密功能的初中級開發(fā)者使用。壓縮包內(nèi)共 18 個文件約 5.16MB涵蓋 32 位與 64 位可執(zhí)行程序exe、配套鏈接庫lib、調(diào)試符號文件pdb以及必要的頭文件h并附帶了兩個示例數(shù)據(jù)庫db和說明文檔txt結(jié)構(gòu)清晰便于按需選用。工具包同時提供 debug 版本方便開發(fā)階段跟蹤問題正常發(fā)布時可選用 release 版本。目前已有 623 人學(xué)習(xí)下載說明其在 SQLite 數(shù)據(jù)庫加密場景中具有較高的參考價值。跟隨內(nèi)含教程開發(fā)者可以快速掌握 SQLCipher 的編譯連接、庫替換與數(shù)據(jù)庫加密/解密流程減少環(huán)境配置踩坑。1. sqlcipher 3.0.1 是什么給 SQLite 加一層你不能省掉的加密殼sqlcipher 3.0.1 是 SQLite 的加密分支在 Windows 上以預(yù)編譯二進(jìn)制加使用教程的形式提供。核心價值一句話它對數(shù)據(jù)庫文件做 AES-256 透明加密應(yīng)用層 SQL 不用改一行加密邏輯全在存儲層完成。很多項目把用戶表、訂單表明文丟在磁盤上數(shù)據(jù)庫文件被人拷走任意 SQLite 工具都能直接打開連密碼都不需要。這套資源解決的就是這個痛點尤其適合 Windows 桌面軟件、工控數(shù)據(jù)采集和老業(yè)務(wù)系統(tǒng)升級。它自帶命令行工具和使用教程新手能照著建庫、加密、遷移熟手可以直接拿來做批量密鑰管理和存量庫轉(zhuǎn)換。要注意它不是 SQLite 的替代品而是同一套語法的加密版運行時后面很多坑都源于這一句。2. 加密原理與版本選型為什么 3.0.1 仍值得用它和 SQLite 到底差在哪2.1 透明加密的真實機制SQLCipher 的加密不是在 SQL 層做的而是在 pager 層。每個數(shù)據(jù)庫頁面在落盤前被加密讀取時先解密再交給上層。這意味著你的 SQL 語句、ORM 框架完全不需要知道加密的存在只要在連接建立后執(zhí)行一次PRAGMA key之后的一切讀寫都是透明的。默認(rèn)情況下每個數(shù)據(jù)庫頁是 4096 字節(jié)加密算法是 AES-256-CBC密鑰由用戶提供的 passphrase 通過 PBKDF2-HMAC-SHA1 派生而來。3.0.1 的默認(rèn) KDF 迭代次數(shù)是 4000 次。這里有第一個容易誤解的點PRAGMA key abc里那串字符串并不是最終的加密密鑰它只是派生密鑰的輸入材料。派生參數(shù)迭代次數(shù)、頁面大小、HMAC 算法只要有一個不一致哪怕 passphrase 一字不差也解不開庫。我在幫某開發(fā)者排查一個打不開的庫時發(fā)現(xiàn)就是源庫用 2.x 的老默認(rèn)參數(shù)創(chuàng)建而新工具開了 3.x 的默認(rèn)參數(shù)密碼完全對不上。另一個機制是每庫隨機 salt。每個加密庫創(chuàng)建時都會寫入隨機鹽值所以同樣的 passphrase 加密出來的兩個庫文件頭內(nèi)容也不一樣。這就排除了一個常見幻想想通過比對文件頭判斷兩個庫是否同密碼。實際做法是把兩個庫分別用同一個 key 打開用PRAGMA schema_version這類命令驗證會話是否建立成功這個驗證思路在第 6 章會展開。3.0.1 生成的庫文件頭前 16 字節(jié)仍然保留SQLite format 3這個標(biāo)識。這意味著普通 SQLite 工具能把它識別為一個 SQLite 文件但第 16 字節(jié)之后全部是加密數(shù)據(jù)識別完就被打回原形。如果你用十六進(jìn)制工具翻開一個加密庫看到前 16 字節(jié)正常、后面全是高熵亂碼那才是加密真正生效的樣子。2.2 3.0.1 與 4.x 的差異維護(hù)老庫時最容易踩的版本坑加密庫是版本綁定的這是我從一次數(shù)據(jù)恢復(fù)事故里換來的教訓(xùn)。某跨平臺系統(tǒng)的數(shù)據(jù)庫用了 SQLCipher 3.x 加密運維同學(xué)在網(wǎng)上下了一個最新 4.x 命令行工具去打開結(jié)果報file is not a database當(dāng)場以為數(shù)據(jù)庫損壞了。其實只是 4.x 的默認(rèn)派生參數(shù)和 3.x 完全不同需要先切換兼容模式。核心差異集中在三處KDF 迭代次數(shù)、HMAC 算法、默認(rèn)頁面大小。3.0.1 默認(rèn)是 4000 次迭代加 HMAC-SHA1頁面 4096 字節(jié)4.x 默認(rèn)是 256000 次迭代加 HMAC-SHA512頁面仍然是 4096。4.x 為了向前兼容提供了PRAGMA cipher_compatibility 3打開 3.x 庫前先執(zhí)行這一句就能識別但反過來3.0.1 里并沒有這個 pragma你要做的反而是用PRAGMA kdf_iter 4000、PRAGMA cipher_page_size 4096這類參數(shù)去對齊源庫創(chuàng)建時的設(shè)置。更老的 2.x 庫默認(rèn)頁面是 1024 字節(jié)3.0.1 打開時必須先設(shè)cipher_page_size 1024否則 HMAC 計算對不齊照樣報錯。簡單記憶越老的工具打開新庫基本無解新工具打開老庫得靠參數(shù)對齊。下面這張表寫清了各世代的關(guān)鍵差異也是我排查「密碼對但打不開」問題的對照表版本默認(rèn)頁面大小默認(rèn) KDF 迭代HMAC 算法打開 3.x 庫1.x/2.x10244000HMAC-SHA1需設(shè) page_size10243.0.140964000HMAC-SHA1默認(rèn)即可4.x4096256000HMAC-SHA512設(shè) cipher_compatibility32.3 資源包內(nèi)容清單與適用邊界這類預(yù)編譯包通常包含幾類東西一個改名的命令行程序本質(zhì)是內(nèi)置了 SQLCipher 的 sqlite3 shell、配套的 OpenSSL 運行庫、一份或多份使用教程文檔有的包還會帶上編譯好的 DLL 供 C/C 調(diào)用。標(biāo)題里已經(jīng)寫明含使用教程具體文件數(shù)量和格式以包內(nèi)為準(zhǔn)我拿到手第一步是把整個目錄固定放到一個單獨的文件夾里不要急著拷貝 exe 到 System32——原因后面 DLL 那節(jié)會說。適用邊界也要先劃清。這套包能解決「本地文件加密、命令行管理、存量明文庫轉(zhuǎn)加密」這三類訴求它不解決跨版本互通不解決 ODBC/JDBC 驅(qū)動集成那需要額外編譯對應(yīng)驅(qū)動也不保證你的程序語言庫能直接用——很多語言的 sqlite3 模塊是官方 SQLite不是 SQLCipher你需要在程序側(cè)換成 SQLCipher 的編譯版本或者走命令行/擴展接口。先確認(rèn)你的運行時是哪一個再動手。3. 環(huán)境搭建與命令行實戰(zhàn)讓加密庫能開、能寫、能關(guān)3.1 目錄結(jié)構(gòu)與 PATH 配置先把壓縮包解壓到一個無中文、無空格的路徑下比如某臺 Windows 機器上的C:\sqlcipher301。注意加入 PATH 時也優(yōu)先用這個短路徑避免某些老版本命令行工具在帶空格的路徑下解析參數(shù)出問題。我一般會用set PATHC:\sqlcipher301;%PATH%設(shè)置會話級環(huán)境變量只在當(dāng)前窗口生效而不是永久寫進(jìn)系統(tǒng)環(huán)境變量——原因是這臺機器上可能還有其他 SQLite 工具PATH 寫死容易造成名字沖突。驗證安裝是否正常核心看兩步。第一步執(zhí)行版本檢查sqlcipher -version正常會輸出類似3.0.1和一個日期如果你看到的是SQLite 3.x之類不帶 SQLCipher 標(biāo)識的輸出說明你調(diào)用的根本不是 SQLCipher 版本而是系統(tǒng)里另一個 sqlite3.exe。第二步直接啟動交互式 shell 并執(zhí)行一句PRAGMA cipher_version;sqlcipher test.db sqlite PRAGMA cipher_version;能返回一串版本號字符串說明這個 shell 確實內(nèi)嵌了加密組件。如果返回 unknown 或者干脆報錯說明二進(jìn)制包不完整或依賴缺失先回第 5 章查 DLL 問題別往下走。這一步有兩個細(xì)節(jié)值得養(yǎng)成習(xí)慣。一是始終用全名調(diào)用不要圖省事把 sqlcipher.exe 改名為 sqlite3.exe因為后續(xù)你會同時用到官方 sqlite3.exe 做對比測試兩個文件同名會把你自己繞暈二是test.db這個名字只是占位SQLite 系工具對不存在的文件會自動新建對已存在的文件會用當(dāng)前 key 嘗試打開理解了這個行為后面很多「怎么打不開」的問題就有一半答案了。3.2 首次建庫PRAGMA key 的兩種寫法進(jìn)入交互式 shell 之后第一件事不是建表而是設(shè)置 key。這條順序是硬性的必須在任何讀寫操作之前設(shè)置 key。我見過有人在建表之后才想起來設(shè) key結(jié)果整個庫前半段是明文元數(shù)據(jù)后半段才開始加密磁盤上落了一個半加密的畸形文件。sqlcipher encrypted.db sqlite PRAGMA key my-decent-passphrase; sqlite CREATE TABLE user ( id INTEGER PRIMARY KEY, name TEXT NOT NULL, email TEXT ); sqlite INSERT INTO user (name, email) VALUES (A同學(xué), aexample.com); sqlite .quit這段沒有任何建庫動作但文件已經(jīng)生成了。PRAGMA key可以接受兩種形式普通字符串和 64 字符的十六進(jìn)制串。字符串會被 PBKDF2 派生適合人類記憶的密碼十六進(jìn)制串則被當(dāng)作 256 位原始密鑰直接使用跳過 KDF 派生過程。兩者不可混用同一個庫用字符串 key 創(chuàng)建就不可能用對應(yīng)的 hex 值打開因為進(jìn)的是兩條完全不同的密鑰處理路徑。參數(shù)選擇上如果業(yè)務(wù)方要求「密碼好記」就用字符串 key 配上 4000 次迭代的默認(rèn)派生如果是程序內(nèi)部硬編碼的密鑰我傾向于PRAGMA key x...這種 hex 形式——它不依賴派生算法的一致性未來升級到 4.x 時哪怕 KDF 默認(rèn)值變了只要原始密鑰串一致兼容性風(fēng)險小得多。代價是這串 64 位 hex 必須妥善保管丟了你沒有任何找回手段。3.3 關(guān)閉后重開驗證 key 是否真正生效建好庫以后必須做一次完整的關(guān)閉重開驗證。很多新手在同一個會話里測試全程都帶著 key感覺一切正常直到程序重啟才發(fā)現(xiàn)密碼根本對不上。標(biāo)準(zhǔn)做法是退出 shell重新啟動用同一個 passphrase 打開然后執(zhí)行一條查詢sqlcipher encrypted.db sqlite PRAGMA key my-decent-passphrase; sqlite SELECT * FROM user;能讀出剛才插入的那行數(shù)據(jù)說明 key 和派生參數(shù)全都正確。更該做的是反向測試故意輸錯一個字符再執(zhí)行同樣的查詢。如果實現(xiàn)符合預(yù)期你會看到file is encrypted or is not a database之類的錯誤如果你輸錯了密碼居然還能查出數(shù)據(jù)那說明這個庫根本沒有加密——這類情況通常是你把加密命令后綴的CREATE TABLE建到了別的文件里或者環(huán)境變量指向了錯誤的運行時。反向測試雖然反直覺但它的價值是它驗證的是「加密邊界」而不是「數(shù)據(jù)內(nèi)容」。正向查詢證明密碼對反向查詢證明數(shù)據(jù)確實不可讀兩層都過了這個庫才算真正交付。我每次給業(yè)務(wù)方演示加密效果時都做這兩步用后者做演示效果比任何 PPT 都直觀。4. 業(yè)務(wù)遷移實戰(zhàn)把明文庫完整轉(zhuǎn)成加密庫的兩種路徑4.1 ATTACH 方案官方說的標(biāo)準(zhǔn)遷移大多數(shù)存量項目手里都有一個長期未加密的 SQLite 文件比如data.db里面幾十張表帶索引、觸發(fā)器不可能手工重建。SQLCipher 提供了一條官方遷移路徑sqlcipher_export()配合 ATTACH把主庫的全部內(nèi)容導(dǎo)出到另一個庫。主庫是新建的加密空庫目標(biāo)庫是那個明文老庫導(dǎo)出方向別搞反我最初就干反過一次調(diào)了半天發(fā)現(xiàn)明文庫越導(dǎo)越大。sqlcipher new_encrypted.db sqlite PRAGMA key migration-pass-2024; sqlite ATTACH DATABASE data.db AS plaintext KEY ; sqlite SELECT sqlcipher_export(plaintext); sqlite DETACH DATABASE plaintext; sqlite .quit第一行打開了一個新的空庫并設(shè)好 key此時庫文件雖然存在但還沒有任何表結(jié)構(gòu)。第三行的ATTACH ... KEY 是關(guān)鍵空字符串表示目標(biāo)庫是明文 SQLite不參與加密如果你這里漏掉了 KEY 子句或者寫了個非空密碼老庫會以加密身份被掛進(jìn)來導(dǎo)出立刻報錯。sqlcipher_export(plaintext)會讀取主庫的 schema 和數(shù)據(jù)寫入到 attached 的明文庫里之后 detach 分離關(guān)閉會話。整個過程中data.db是被寫的那一方而new_encrypted.db那個空庫只是數(shù)據(jù)源的概念容器。導(dǎo)出完成后要檢查三樣?xùn)|西行數(shù)、索引、觸發(fā)器。我一般會這樣驗證sqlcipher data.db sqlite SELECT COUNT(*) FROM user;再對導(dǎo)出的加密庫做同樣的查詢兩邊行數(shù)對比。更進(jìn)一步要對比索引是否完整因為sqlcipher_export對大多數(shù)對象都覆蓋但個別版本對sqlite_sequence、PRAGMA user_version這類元數(shù)據(jù)不見得完整遷移。程序代碼里如果依賴user_version做 schema 版本判斷遷移后要單獨執(zhí)行一次PRAGMA user_version 原來的值;補上否則程序啟動時可能誤判庫版本觸發(fā)重建邏輯。4.2 兼容模式老庫打不開時先查這兩個參數(shù)如果手頭是更老的 SQLCipher 1.x/2.x 庫4.1 的流程會卡在第一步ATTACH或打開時報file is encrypted or is not a database。問題往往不是密碼錯而是老庫創(chuàng)建時的默認(rèn)參數(shù)和 3.0.1 不一致。2.x 時代的默認(rèn)頁面大小是 1024 字節(jié)KDF 迭代同樣 40003.0.1 默認(rèn)是 4096。HMAC 計算、頁內(nèi)加密都是按頁做的頁面大小對不上解密頭和后續(xù)頁全部錯位。打開這類老庫前先執(zhí)行兩個 PRAGMA 對齊參數(shù)sqlcipher legacy.db sqlite PRAGMA cipher_page_size 1024; sqlite PRAGMA kdf_iter 4000; sqlite PRAGMA key old-passphrase; sqlite SELECT COUNT(*) FROM sqlite_master;參數(shù)設(shè)置必須在設(shè)置 key 之前完成因為PRAGMA key觸發(fā)的派生過程會直接消費這些參數(shù)。順序錯了的話key 已經(jīng)用錯誤的迭代次數(shù)派生完畢你再改 kdf_iter 也不會重新派生。如果你手頭這批老庫頁面大小不是 1024可以試著用 512、2048、4096 逐個試每次都要新建會話再設(shè)參數(shù)因為庫打開失敗后當(dāng)前會話的加密上下文已經(jīng)不可信繼續(xù)在同一會話里改參數(shù)通常不起作用。這套「先參數(shù)、后密碼、再驗證」的操作順序?qū)λ锌绨姹緢鼍岸歼m用。遇到打開失敗第一反應(yīng)不是懷疑密碼錯了而是先確認(rèn)源庫是在哪個 SQLCipher 版本下創(chuàng)建的。資源包里的使用教程如果附帶了版本變更說明里面通常會寫參數(shù)對照那才是第一手依據(jù)。4.3 改密碼與多密鑰切換rekey 和 key 的正確時機運行中的業(yè)務(wù)系統(tǒng)需要定期改密這是常見需求。SQLCipher 里改密碼用PRAGMA rekey而不是重新建庫導(dǎo)數(shù)據(jù)sqlcipher encrypted.db sqlite PRAGMA key old-passphrase; sqlite PRAGMA rekey new-passphrase; sqlite .quitrekey本質(zhì)上是對全庫逐頁重新加密頁數(shù)多時耗時明顯期間一旦斷電或進(jìn)程被殺庫文件可能處于新舊 key 交錯的中間狀態(tài)。我的習(xí)慣是改密前強制復(fù)制一份 .db 文件做備份再執(zhí)行 rekey改完立刻做一次關(guān)閉重開驗證。有一個場景容易翻車數(shù)據(jù)庫開啟了 WAL 模式而 WAL 文件里還殘留著用舊 key 寫入的日志頁rekey 只處理了主庫文件沒處理 WAL。這時程序重啟后讀取 WAL 里的舊頁可能報錯或讀出亂碼。解決方式是 rekey 前先執(zhí)行一次PRAGMA wal_checkpoint(TRUNCATE);把 WAL 內(nèi)容合入主庫并清空日志文件再執(zhí)行 rekey。多密鑰切換則是另一個邏輯一個進(jìn)程內(nèi)同時要訪問兩個不同 key 的庫。PRAGMA key只作用于當(dāng)前主庫連接第二個庫可以通過 ATTACH 掛進(jìn)來并單獨指定 keysqlcipher main.db sqlite PRAGMA key main-pass; sqlite ATTACH DATABASE other.db AS other KEY other-pass; sqlite SELECT * FROM other.user;這樣主庫和附加庫用各自獨立的密碼互不干擾。有一個隱藏細(xì)節(jié)ATTACH 語句里的 KEY 子句使用的是與主庫PRAGMA key相同的派生參數(shù)配置。也就是說如果主庫設(shè)了cipher_page_size 1024附加庫也會用 1024 去嘗試解密如果附加庫實際上是 4096 默認(rèn)創(chuàng)建的你需要在 ATTACH 之前把參數(shù)切回去或者接受它對不上。多庫混用時最好讓所有庫用同版本、同參數(shù)創(chuàng)建否則就得按 4.2 那套逐庫對齊的路子來。5. 常見問題與避坑Windows 下的六個翻車現(xiàn)場5.1 啟動即閃退或報缺少 DLL現(xiàn)象雙擊或命令行啟動 sqlcipher 時提示缺少libeay32.dll、ssleay32.dll或者彈窗提示程序無法正常啟動有時啟動不報錯但執(zhí)行PRAGMA key后程序直接退出。原因3.0.1 的 Windows 預(yù)編譯版通常依賴 OpenSSL 1.0.x 運行庫系統(tǒng)里沒有對應(yīng) DLL或者 PATH 中存在另一份更高版本的 OpenSSL名字相同但符號不兼容。SQLCipher 啟動時加載到錯的依賴Crash 在加密初始化階段。解決把資源包內(nèi)自帶的 DLL 與 exe 放在同一個目錄下優(yōu)先保證 exe 先在本地目錄找到依賴。確認(rèn)方法用where libeay32.dll查看當(dāng)前實際加載路徑如果在 System32 或其他軟件目錄里找到了另一份就調(diào)整 PATH 順序或者在啟動腳本里先用全路徑把程序目錄釘死。命令行方式可以直接寫set PATHC:\sqlcipher301;%PATH% C:\sqlcipher301\sqlcipher.exe test.db注意全路徑調(diào)用 exe避免系統(tǒng)目錄下的同名程序搶先。如果還閃退繼續(xù)做一次純粹的依賴檢查。5.2 官方 sqlite3 工具打不開加密庫現(xiàn)象用系統(tǒng)里的 sqlite3.exe 打開加密數(shù)據(jù)庫文件報file is encrypted or is not a database但同一個文件用 sqlcipher 加正確密碼就能正常讀。原因這是正?，F(xiàn)象而不是故障。官方 SQLite 沒有解密能力加密庫在它眼里就是非法格式。SQLCipher 3.x 保留了前 16 字節(jié)的SQLite format 3標(biāo)識所以它還能識別出這是 SQLite 家族的文件但再往后全是密文只能報錯。這個報錯信息是「不是數(shù)據(jù)庫」和「是加密的數(shù)據(jù)庫」的合并結(jié)果。解決這一步不需要修只需要確認(rèn)你操作加密庫時永遠(yuǎn)使用 sqlcipher 運行時。項目代碼里也要排查是否誤引用了官方 sqlite3 的驅(qū)動——很多語言默認(rèn)的 sqlite 模塊就是官方版沒有 SQLCipher 編譯選項時連接加密庫必現(xiàn)此錯。處理方式是換用 SQLCipher 的驅(qū)動或增加 shell 調(diào)用層。另外我在做文件備份時會把 .db 和 -wal、-shm 文件一起備份千萬別只拷主文件WAL 里的最近提交會丟。5.3 密碼明明正確卻提示解密失敗現(xiàn)象PRAGMA key correct-pass正常執(zhí)行但一執(zhí)行SELECT立刻報file is encrypted or is not a database。換了密碼、重裝了工具都沒用。原因密碼字符串經(jīng)過 KDF 派生后的結(jié)果不對。最常見的因素是kdf_iter或cipher_page_size與庫創(chuàng)建時不匹配。另一個隱蔽原因是密碼前后混入了不可見字符比如從配置文件中讀出的密碼帶\r\n換行符或者交互式 shell 里復(fù)制粘貼時帶了空格。還有一種情況源庫創(chuàng)建時密碼不是字符串、而是 hex 形式的原始密鑰那么你拿字符串形式的密碼去解走的派生路徑完全不同。解決先查創(chuàng)建時機的配置確認(rèn)是哪個 SQLCipher 版本建的庫、默認(rèn)參數(shù)是多少。2.x 庫按 4.2 的步驟設(shè)cipher_page_size10243.x 庫確認(rèn) 4096。然后檢查密碼的精確字節(jié)我一般用十六進(jìn)制查看配置文件末尾確認(rèn)沒有隱形換行。最后新建一個同版本空庫用同一個 key 創(chuàng)建、關(guān)閉、重開如果這個流程能打開說明參數(shù)沒問題問題出在源庫的創(chuàng)建參數(shù)上。5.4 rekey 改密后舊密碼還能打開一部分?jǐn)?shù)據(jù)現(xiàn)象執(zhí)行完P(guān)RAGMA rekey new-pass后退出程序重新啟動用新密碼打開部分表或部分行讀取異常用舊密碼反倒能正常打開。原因rekey 執(zhí)行時數(shù)據(jù)庫開啟了 WAL 模式日志文件里還殘留舊 key 加密的頁。主庫文件已經(jīng)被新 key 重寫但程序啟動時先從 WAL 恢復(fù)日志頁而這些頁是舊 key 加密的于是出現(xiàn)新舊交錯的讀寫異常。舊密碼能打開是因為日志頁還是舊 key恰好能把 WAL 讀完。解決改密前先執(zhí)行PRAGMA wal_checkpoint(TRUNCATE);把 WAL 合入主庫并清空再執(zhí)行 rekey。改完之后再執(zhí)行一次 checkpoint 并關(guān)閉所有連接。如果已經(jīng)發(fā)生交錯狀態(tài)先把當(dāng)前庫文件整體備份然后嘗試用舊密碼打開執(zhí)行PRAGMA wal_checkpoint(TRUNCATE)把殘留頁合并再用新密碼執(zhí)行一次 rekey。這個恢復(fù)流程不保證 100% 成功所以 rekey 前做文件備份是我的固定動作從不跳過。5.5 把明文庫改名就當(dāng)加密完成現(xiàn)象把data.db改成data.db.sqlcipher或者用壓縮工具打包加密實際上文件內(nèi)容還是明文結(jié)構(gòu)用官方 sqlite3 工具照樣能打開讀出全部表。原因文件改名只是改了擴展名數(shù)據(jù)庫頁內(nèi)容沒有任何變化壓縮包的加密是外層加密解壓后 file 內(nèi)容本身還是明文。SQLCipher 的透明加密不是對文件整體做一次 AES而是逐頁加密必須用 sqlcipher 命令行或sqlcipher_export重寫整個文件。解決按 4.1 的 ATTACH 方案走一遍生成真正逐頁加密的新文件。驗證方法用 hexdump 查看新文件數(shù)據(jù)區(qū)應(yīng)該看不到可讀文本而改名后的老文件的數(shù)據(jù)區(qū)里能直接看到CREATE TABLE之類的 SQL 文本殘留。這個驗證成本極低卻是我每次交付前必做的一步。5.6 字符串 key 與 hex key 混淆現(xiàn)象A 機器用PRAGMA key abc123加密B 機器改用PRAGMA key x616263313233想打開結(jié)果失敗。兩邊的運維都認(rèn)為是同一個密碼各自都確認(rèn)沒寫錯。原因前者是 passphrase需要 KDF 派生后者是 24 字節(jié)的原始密鑰直接作為 256 位密鑰的一部分使用位數(shù)不足時按規(guī)則補齊。兩種模式從密鑰生成第一步就分道揚鑣唯一的共同點是它們都叫 key實際卻是完全不同的兩樣?xùn)|西。解決統(tǒng)一約定一種形式并且寫進(jìn)項目文檔里。程序側(cè)無論是配置文件還是啟動參數(shù)都要在 key 字符串前加明確的類型標(biāo)記。排查時先問一句當(dāng)初建庫用的是字符串密碼還是 hex 密鑰通常這一句就能定位問題。順帶建議hex 密鑰長度必須是 64 個十六進(jìn)制字符少于或多于都會導(dǎo)致 SQLCipher 內(nèi)部報錯不要用短字符串去硬湊 hex 格式。6. 驗證技巧用十分鐘確認(rèn)加密真的生效加密庫的交付不能只靠「PRAGMA key 沒報錯」來判斷那只能說明密鑰設(shè)置成功不能證明數(shù)據(jù)已經(jīng)密文落盤。我給業(yè)務(wù)方演示時固定跑一遍三件套驗證第一件是十六進(jìn)制查看頭部第二件是文本提取掃描第三件是錯誤密碼探測。先看文件頭形態(tài)hexdump -C -n 64 new_encrypted.db正常輸出是這樣的形態(tài)前 16 字節(jié)是53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00即SQLite format 3的 ASCII 碼但從第 16 字節(jié)開始也就是 salt 區(qū)和第一個頁的起始處全部是隨機高熵字節(jié)沒有任何可讀 ASCII 字符串。對比一下明文庫的同一位置你能看到CREATE TABLE的 ASCII 文本直接暴露在數(shù)據(jù)區(qū)。這一步基本就能確認(rèn)加密范圍覆蓋到了數(shù)據(jù)頁。再做一次全文件文本掃描strings encrypted.db | head -20加密庫輸出里如果還能看到表名、字段名之類的業(yè)務(wù)詞說明有部分區(qū)域未被加密——常見原因是庫創(chuàng)建時先建了表、再設(shè)置的 key或者 attach 導(dǎo)出時目標(biāo)庫帶上了老 schema 的明文殘留。我遇到過一次一個庫能打開但 strings 輸出里能看到完整的建表語句最后定位是程序代碼里把PRAGMA key放在了建表語句之后庫的 sqlite_master 區(qū)域以明文寫入。這種庫嚴(yán)格說是半加密狀態(tài)雖然實際數(shù)據(jù)行已經(jīng)加密但表結(jié)構(gòu)元數(shù)據(jù)泄露了。處理方法是按 4.1 重新導(dǎo)出一次生成規(guī)范的全加密文件。第三件是錯誤密碼探測sqlcipher encrypted.db sqlite PRAGMA key wrong-pass; sqlite SELECT name FROM sqlite_master LIMIT 1;理想結(jié)果是任何查詢都報錯或返回空說明數(shù)據(jù)確實被 key 鎖住。如果這一句能返回表名立刻停下檢查要么是庫沒加密要么是設(shè)置 key 的會話上下文沒有落在當(dāng)前連接上——有些客戶端庫在連接池里把 key 設(shè)置到了一條連接查詢走了另一條連接導(dǎo)致你看到「能查出來」的假象實際是連接錯位。從那以后我每次拿到一個新的加密庫第一件事就是跑這三板斧hexdump 看頭、strings 掃文本、錯誤密碼探查詢?nèi)歼^了才敢把庫交付給業(yè)務(wù)方改密、遷移、升級版本時也強制走一遍不省略不跳步。這套流程幫我擋掉了至少三次「以為加密了、其實裸奔」的事故。這次分享的 sqlcipher 3.0.1 Windows 包解法路徑都在上面了參數(shù)和坑位對照著排應(yīng)該能省你不少時間希望幫到你。本文還有配套的精品資源點擊獲取