プログラムで保存したファイルを暗号化する必要がありますか
データを保存する形式を決定しようとしています。この質問が決定に役立つことを願っています。私が書いているプログラムは、Word=meaning（辞書ではなく、単なる例です）が含まれる「データベース」を使用しています。私は、プログラムなしでこれらの「データベース」を手動で簡単に編集できるようにしたくありませんが、同時に、プログラミング言語（C＃、PHP、JavaとObjective C）間の相互運用性を探しています。 ）
現時点では、主な候補はSQLite、XML、およびSQL Server CEです（PHPはServer CEをサポートしていませんが、それほど問題になる必要はありません）。本当に、私の質問は、暗号化を使用する必要があるのかということです。暗号化をサポートしている場合、暗号化キーをどのように処理しますか？長くて複雑な文字列を生成するだけですか？
それともバイナリで十分ですか？データベースに重要なものはありませんが、isEditable 'キー'を使用して、編集を許可するかどうかをプログラムが認識できるようにしたいと考えています。また、自分のファイル拡張子も使用したいと思います。
いいえ、複数の理由でエンコードしないでください。
- それらをよりオープンにすることはあなたにとってより少ない仕事です。あなたのビジネスは必要それを隠すために余分な仕事を費やしますか？
- 暗号化すると、ロックインが発生します。ロックインは販売機能ではありません
- アプリが復号化した場合、それはアプリを調べることで暗号化が解読される可能性があることを意味します。そのため、わずかな利益で作業を完了しただけです。誰かが解読するとすぐに、誰でも繰り返すことができます。
- 開いていると、ユーザーは、予測していなかった、アプリに追加しなかったデータを使って何かを行うことができます。これは、ユーザーに追加のユーティリティを提供したことを意味します。
- パートナーは処理ロジックを記述する必要がないため、オープンデータは将来のパートナーシップを容易にします。
- オープンデータは、そのデータを使用する競合ツールが魔法のように現れることを意味するわけではありません-競合他社はまだ独自のソフトウェアを作成する必要がありますが、これはあなたのソフトウェアを使用するほど良い提案ではない可能性があります-誰かが使用しないためにどれだけの努力をしたいかあなたのソフトウェア？
これは決して完全なリストではなく、頭に浮かんだものだけです。
暗号化について人々が常に見落としている非常に重要な事実の1つは、データの整合性を保証するために暗号化がまったく行われないことです。暗号化は機密性の問題を解決します。権限のないユーザーがデータを読み取るのを防ぎます。暗号化は、誰かが有用な方法でデータを変更することを困難にしますが、それは正しい問題を解決していません。
他のプログラムがデータを変更することを心配している場合、実際に必要なのはデータの信頼できるフィンガープリントです。これを行う一般的な方法は、プログラムがデータベースを変更するときにデータベースのハッシュを生成し、そのハッシュに秘密鍵で署名することです。データベースをロードしたら、ハッシュを計算し、それを署名付きハッシュと比較して、署名が有効であることを確認します。
理論の問題は解決されたので、実際には、データの暗号化でこの種のことを十分に実現できる可能性があることに注意してください。暗号化された構造化データを盲目的に変更すると、データベースが破損する可能性があります。そのため、ユーザーはアプリケーション以外のものを使用してデータベースを変更できなくなります。他の誰もあなたのデータを読み取りできないことを確認したい場合（質問では明確ではありませんでした）、おそらく暗号化したままにして、それで済ませても安全です。
データの改ざんや表示を制限しますか？それぞれの潜在的なソリューションには、わずかに異なる実装が必要になります。
改ざんにはハッシュを使用します。実際の例として、私が取り組んだ1つのアプリケーションは、文字列やファイルのハッシュを計算します。ユーザーがファイルをダウンロードしたときに、ハッシュを確認しました。ユーザーがファイルを開いたときに、ハッシュを確認しました。これは、クライアントがエンドユーザーによるファイル（jpgなど）の改ざんを望まなかったためです。これにより、ユーザーがファイルを改ざんすることを防ぎました。改ざんした場合、ハッシュが一致せず、エラーが発生したためです。任意のファイル/文字列をハッシュできます。ユーザーが文字列やファイルを問題なく改ざんしたくない場合は、そのデータのハッシュを文字列/ファイルと一緒に保存します。パスワードを暗号化する必要はありません。解決策は、パスワードをソルトしてハッシュすることです。その場合、データストアとアプリケーションはユーザーパスワードを認識していません。
暗号化は、クレジットカードや個人データなどの情報を隠すために使用されます。法的要件および規制要件により、暗号化する必要があるものを定義する必要があります。アプリケーションが機密データを格納している場合、アクセスを防ぐ方法の1つは暗号化です。 ACLなどを定義してアクセスを制限することもできますが、ユーザーにのみデータを表示させたい場合は、暗号化が最善のオプションです。
また、必要な場合にのみ実装してください。上記の例に戻ると、元々、アプリケーションには改ざん防止機能がありました。ユーザーはファイルをダウンロードし、ローカルで開いて表示しました。ユーザーからファイルを改ざんできないという要求があった後、ハッシュチェックを実装しました。設計時に、ファイルシステムへのアクセスをダウンロードされたファイルに制限するか、ハッシュを使用するかの2つのオプションを検討しました。ハッシュを選択したのは、アップロード時にすでに計算していたため、ユーザーが表示する前にチェックを追加するのは比較的簡単でした。
探しているのが外部編集を思いとどまらせることだけで、異なる実装言語間の相互運用性を提供する場合は、単にファイルを圧縮することを検討してください。テキストエディタで開くとラインノイズのように見えますが、標準の圧縮アルゴリズムを使用すると、最も一般的な言語のファイル圧縮ライブラリを見つける（または書き込む）ことができるはずです。データセットが大きくなった場合でも、ストレージスペースを節約できるというメリットがあります。
私があなたの質問を理解しているように、誰かがあなたのデータベースを変更したり見たりしても、あなたは本当に気にしません。
Daenyth あなたがそうすべきではない理由は良い議論になりますが、とにかくそれを使うことにした場合は、いくつか考えてみてください物事：
- 暗号を正しく理解するのは難しい
AESを使用してデータを暗号化する場合でも、データを暗号化する場合でも、データの価値は実際には暗号化/保護を必要としません。また、将来、別の言語で、または別のライブラリを使用してデータを読み取ることが難しくなる可能性があります。
- 難読化したほうがいいです
つまり、単純なBase64で十分です。もちろん、それは Dan のようにデータの整合性を検証するためには何もしませんが、署名の実装には依然としてコストがかかりすぎます。別の方法として、（一部のチェックサム関数の）一連の固定チェックサムに準拠するように、ファイルにパディングを追加することができます。署名よりはるかに軽量ですが、それでもかなり高価です。
将来、リモートデータベースへの信頼できる接続が必要になった場合は、実装時に もう一度質問してください 。
SQLiteとXMLについては、同じトピックについて StackOverflow に関する質問があります。閉じていますが、いくつかの優れた答えがあります。
編集：Javaを使用している場合は、ファイルを圧縮することを検討してください。判読できないバイナリブロブとa checksum 。C＃にもこのバージョンがあると思いますが、その言語には慣れていません。