問題タブ [sqlcipher]

PHP アプリケーションで暗号化された sqlite データベースをサポートすることを検討しています。私はPHPのSQLite3拡張機能を使用していますが、それらはすでに暗号化方法をサポートしているようです.少なくともSQLite3::__constructは暗号化キーを渡すことができます.

私が理解できなかったのは、ドキュメントでどの暗号化ライブラリについて話しているかということです。ググってみると、以下が見つかりました。

• sqlcipher
• sqlite 参照
• sqlite クリプト

私には明らかではないのは次のとおりです。

• これらのライブラリが SQLite3 とどのように統合されるか
• 暗号化キーの指定やデータアクセスの設定などに関して、それらが互いに互換性を共有している場合。
• アプリケーションで自動的に検出でき、SQLite3 インストールがサポートしている暗号化ライブラリがある場合、アプリケーションがさまざまな暗号化ライブラリをサポートすることが可能になります。

どんな助けでも大歓迎です！

私のアプリは、FTS3でSQLiteデータベースを使用して製品検索を行います。SQLCipherを使用してデータベースを暗号化しようとしていますが、データベースのサイズが膨らみます（7mb->〜20mb）。

暗号化されたFTSSQLiteデータベースを圧縮する優れた方法があるようには見えません。誰かがこれについて提案がありますか？アプリを20mb3gのダウンロード制限未満に保つには、縮小する必要があります。

ありがとう！

私はリバースエンジニアリングの経験があり、Androidで静かにデータベースにアクセスする人々がいます。作成時にデータベースのみを暗号化して（apk全体を難読化するのではなく）、実行時にデータベースを使用する方法があるかどうかを知りたいです。

私はデータベースに関する知識が少ないので、アセットフォルダー内のDBを保護するための提案は恩恵のようになります。

シナリオ：データベースはsqliteです（データベース内のレコードを暗号化する必要があります。したがって、iOS用のSQL暗号化APIを使用します）

データベースには、次のようなスキーマを持つpartnumberという名前のテーブルがあります。

このテーブルには、約80Kのレコードが含まれています。

UIビューには3つのテキストフィールドがあり、ユーザーは検索語を入力でき、ユーザーがそこに文字を入力するとすぐに検索が行われます。

3つのテキストフィールドは、txtFieldDescription、txtFieldMake、およびtxtFieldModelです。

最初のユーザーがtxtFieldDescriptionに「monitor」として検索語を入力するとします。したがって、各文字で実行されるクエリは次のとおりです。

1.1。

2.2。

3.3。

4.4。

5.5。

6.6。

7。

ここまでは順調ですね。ここで、ユーザーがモデルを検索したい場合を考えてみましょう（txtFieldDescriptionにはまだ「monitor」が含まれています）。したがって、ユーザーはtxtFieldModelをクリックします。ユーザーがモデルをクリックするとすぐに、クエリは次のように実行されます。

このクエリは、説明にモニターが含まれているレコードのすべてのモデルを返します（任意の位置）。

ここで、ユーザーが「sony」という単語を含むすべてのモデルを検索する場合（説明フィールドには引き続きモニターが含まれます）、各文字で実行されるクエリは次のとおりです。

1.1。

2.2。

3.3。

4.4。

ここで、ユーザーがtxtFieldMakeをクリックし、検索語を「1980」と入力すると、実行されるクエリは次のようになります。

1.1。

2.2。

3.3。

4.4。

ここで、txtFieldDescriptionからtxtFieldModelまたはtxtFieldModelからtxtFieldMakeへの移行の時間遅延が大きすぎ、txtFieldModelおよびtxtFieldMakeでは、入力された文字が5秒または6秒後に表示されるため（クエリが処理された後）、カーソルがそこでハングします。 。

分析すると、likeキーワード（'％monitor％'など）の検索語の前のワイルドカードによって実行が遅くなることがわかりました。また、この場合、ANDを挟んだようなキーワードが3つもある可能性があるため、実行時間は確実に長くなります。また、likeの先頭でワイルドカードを使用すると、インデックスが無効になります。

いくつかの追加情報：

1. レコードの総数〜80K

2. SELECTクエリは、テーブルの部品番号（〜80K）に対して毎回実行されます。

3. 私が実行したいくつかのクエリの結果：

   /li>

4. インデックスは次のように作成されます。

   /li>

パフォーマンスを向上させるためのいくつかの代替案：

1. 個別記述の数は2599のみで、makeの数は7129のみであるため、テーブルは、DISTINCT description COLLATE NOCASE出力（合計2599行）を含むテーブルとDISTINCT make COLLATE NOCASE（合計7129行）。モデルに関する限り、行数〜64644は合計レコード数〜82135にほぼ等しいため、別のテーブルを作成しても役に立ちません。ただし、このアプローチの問題は、これらのテーブルをどのように検索するか、各テーブルにどの列が必要か、テーブルをいくつ作成する必要があるかがわからないことです。ユーザーが説明を入力してからモデルを入力し、次に新しい説明を入力するとどうなりますか。

2. この選択クエリの結果はUITableViewに表示されており、ユーザーには一度に最大5行が表示されるためです。したがって、返される行数を500に制限でき、ユーザーがスクロールすると、最後に検索されたレコードまで次の500をフェッチできます。

ただし、ここでの問題は、500レコードしか必要ないにもかかわらず、テーブル全体を検索する必要があることです（SCAN〜80Kレコード）。したがって、最初にテーブルの上位10％のみを検索し、これから上位500行を返すクエリが必要です。次に、上位10％のレコードがすべて検索され、次の10％、次の10％から80000のレコードが検索されます。検索されています（10〜10％のレコードのチャンクで検索する必要があります）。

3. 80Kレコードのテーブルをそれぞれ20Kレコードの4つのテーブルに分割し、4つのテーブルすべてに対して同時に（異なるバックグラウンドスレッドで）検索を実行して、結果セットを取得できる場合。しかし、ここでは、4つの異なるスレッド（バッチ実行の一種）でクエリを実行する方法、結果を組み合わせるタイミング、およびすべてのスレッドが実行を終了したことを知る方法がわかりません。

4. ％monitor％'のように、同じ結果を返すが実行が速く、その関数の使用がインデックスの使用に影響を与えない（つまり、インデックスの使用をバイパスしない）別の関数に置き換えることができる場合、その後、実行が速くなる可能性があります。誰かがsqliteでそのような関数を私に提案できるなら、私はこのアプローチを続けることができます。

これらの選択肢のいずれかを実装するのを手伝ってくれる場合、または他の解決策を提案してくれる場合は、クエリの実行速度を上げることができます。そして、私はすでにこれを試したので、plsはsqliteでFTS（全文検索）を有効にするように教えてくれませんが、正確な手順はわかりません。この質問を辛抱強く読んでくれてありがとう......

編集：

やあみんな、私はいくつかの成功を得ました。選択クエリを次のように変更しました。

そしてビンゴ、検索時間はかつてないほどでした。しかし、問題は、このようにコマンドEXPLAIN QUERY PLANを実行すると、使用したくない個別のBツリーを使用していることを示しています。

出力：

編集：

すみません。上記のアプローチ（検索にrowidを使用）は、元のアプローチよりもデバイスで時間がかかります。キーワードによる区別と順序を削除しようとしましたが、役に立ちませんでした。iPhoneではまだ8〜10秒かかります。plsは私を助けます。

AndroidでSQLCipherを試しています。エミュレーターで 1 つのテーブルといくつかのレコードを含むデータベースを作成する小さなアプリを作成しました。次に、データベースをエミュレーターからデスクトップにプルしました。SQLCipher のドキュメントを見てきましたが、デスクトップ上でデータベースを実際に復号化して、その内容を照会できるようにする方法がわかりません。実際にレコードを挿入したことを確認したかったのです。レコードにアクセスするための最も簡単なプロセスは何ですか? ありがとう。

sqlcipher で作成した暗号化データベースを PC で読み込もうとしていますが、アプリで読み込めません。例えば：

次の結果

これも：

これに戻ります：

私は sdk-7 でコンパイルしています。同じデータベースを暗号化せずに sqlcipher なしで試しても、問題はありません。コンピューターで暗号化されたデータベースをアンドロイドで読み取る方法を誰か教えてもらえますか? 感謝 ;）

Windowsでsqlite3コマンドラインシェルのSQLCipherバージョンをコンパイルし、暗号化されたデータベースを正常に作成しました。次に、この既成のデータベースをAndroidアプリで使用できるかどうかを確認したいと思いました。データベースをAndroidアプリにコピーし、SQLiteDatabase.openDatabaseを呼び出して、Windowsで使用したキーを渡そうとしましたが、次のようになりました。

「原因：info.guardianproject.database.sqlcipher.SQLiteException：ファイルが暗号化されているかデータベースではありません」

誰かが最初にWindowsで暗号化されたデータベースを作成し、次にそのデータベースをアプリケーションと一緒にパッケージ化しようとしたことがありますか？もしそうなら、Androidアプリでデータベースをキーイングして開くためのプロセスは何ですか？

以下のリンクを読みましたが、解決策が見つかりませんでした。

https://groups.google.com/group/sqlcipher/browse_thread/thread/d2694975e8f3809f

Androidのsqlcipherを使用してPCで以前に作成された暗号化されたデータベースを読み取る方法は？

私は自分のアプリでsql cipher（android用sql cipher）を使用していますが、androidタブレットとandroid 2.3より上のバージョンでもうまく動作します.しかし、android 2.2バージョンでクラッシュします.誰もがこの問題について知っていますか？解決策。クラッシュログを含めました

03-24 05:04:26.440: E/AndroidRuntime(15069): 致命的な例外: メイン 03-24 05:04:26.440: E/AndroidRuntime(15069): info.guardianproject.database.sqlcipher.SQLiteException: エラーではありません 03 -24 05:04:26.440: E/AndroidRuntime(15069): info.guardianproject.database.sqlcipher.SQLiteDatabase.dbopen(ネイティブ メソッド) 03-24 05:04:26.440: E/AndroidRuntime(15069): at info. Guardianproject.database.sqlcipher.SQLiteDatabase.(SQLiteDatabase.java:1870) 03-24 05:04:26.440: E/AndroidRuntime(15069): info.guardianproject.database.sqlcipher.SQLiteDatabase.openDatabase(SQLiteDatabase.java:863) で03-24 05:04:26.440: E/AndroidRuntime(15069): info.guardianproject.database.sqlcipher.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:183) 03-24 05:04:26.440: E/AndroidRuntime(15069) : android.view.View.performClick(View.java:2408) 03-24 05:04:26.440: E/AndroidRuntime(15069): android.view.View$PerformClick.run(View.java:8818) 03-24 05:04:26.440: E/AndroidRuntime(15069) : android.os.Handler.handleCallback(Handler.java:587) 03-24 05:04:26.440: E/AndroidRuntime(15069): android.os.Handler.dispatchMessage(Handler.java:92) 03-24 05:04:26.440: E/AndroidRuntime(15069): android.os.Looper.loop(Looper.java:123) 03-24 05:04:26.440: E/AndroidRuntime(15069): android.app.ActivityThread で.main(ActivityThread.java:4627) 03-24 05:04:26.440: E/AndroidRuntime(15069): java.lang.reflect.Method.invokeNative(ネイティブ メソッド) 03-24 05:04:26.440: E/ AndroidRuntime(15069): java.lang.reflect.Method.invoke(Method.java:521) 03-24 05:04:26.440: E/AndroidRuntime(15069): com.android.internal.os.ZygoteInit$MethodAndArgsCaller で.run(ZygoteInit.java:871) 03-24 05:04:26.440: E/AndroidRuntime (15069): com.android.internal.os.ZygoteInit.main (ZygoteInit.java:629) 03-24 05:04:26.440: E/AndroidRuntime ( 15069): dalvik.system.NativeStart.main(ネイティブ メソッド) で

コンテンツ プロバイダーで SqlCipher を使用しています。現在、アプリをロックしたいときは、キャッシュされたパスワードをクリアするだけです。ただし、アプリは開いているカーソルを引き続き使用できます。これは、アプリを再度開くと機密データへのアクセスが許可されることを意味します。アプリにパスワードがない場合、ログイン画面にリダイレクトすることで、この問題を表面的に修正します。

ただし、これらの開いているカーソルにセキュリティ上の問題があるかどうか、または UI アクセスをブロックし続けて心配する必要がないかどうかが心配です。SqlCipher のドキュメントによると、DB 全体を復号化するのではなく、暗号化されたページをオンザフライで読み書きするため、開いているカーソルは依然として安全であると思われます。

ここでの主な懸念は、誰かが携帯電話を紛失し、知識のある個人がこれらの開いているカーソルを使用して機密データを抽出できることです。

これらの手順に従って Windows で sqlcipher をビルドできません。

リンク段階で、gcc は次のエラーを返します。