给sqlite数据库加密的两种方法

前端之家收集整理的这篇文章主要介绍了给sqlite数据库加密的两种方法前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

一个是采用sqlCipher

Need to store sensitive information in your app?SQLCipher extends sqlite enabling transparent encryption and decryption of data using AES. Itssource is available on Github.

sqlite is pluggable. Developers can create extensions and chain them into sqlite’s engine. Using this mechanism,sqlCipher embeds itself low enough in the stack to be transparent. As a developer,you simply issue queries as you normally would and all of the crypto is handled transparently.

sqlCipher’s author,Stephen Lombardo ofZetetic ,has also releasedCryptographically Secure File I/O a library that supports random access file IO on encrypted files.

另外一个

Strong Encryption forCocoa /Cocoa Touch

AES is a strong encryption standard that has mostly replaced the agingDES standard. AES is widely used and fairly secure encryption mechanism (but I am not an expert at cryptography by any stretch of the imagination; I’m trusting experts for that opinion). AES supports three different key sizes,128,192,and 256 (the larger the key,the more secure the encryption and the more processing power it takes toencrypt or decrypt). Apple uses AES-128 and AES-256 in several places in Mac OS X,including for Disk Image encryption.

There are several public-domain implementations of AES. I chose apublic domain implementation of AES by Philip J. Erdelsky to use as the basis some Objective-C categories that make encrypting and decrypting files and data using AES-256 easy.

The first category is onNSFileManager,and allows you toencrypt a file in the filesystem. It takes a file at a particular pathname,encrypts it using a passphrase,and then writes the encrypted contents to a new specified file location. This version has relatively low memory overhead,as it streams the data in chunks both for reading and writing,so only the chunk currently being encrypted is in memory. The category adds two methods toNSFileManager,one for encrypting,the other for decrypting. These methods are the best choice when your source data already exists in the file system,especially on the iPhone,because of how little memory it uses to do the work. Here is an example of using the category onNSFileManager toencrypt a file:

 NSError *error = nil ;
if (![ [ NSFileManager defaultManager ] AESEncryptFile: @" /path/to/input file" toFile: @" /path/to/output file" usingPassphrase: @" My secret password" error: &error ] )
{
NSLog (@" Failed to write encrypted file. Error = %@" ,[ [ error userInfo ] objectForKey: AESEncryptionErrorDescriptionKey ] );
}

There is also a category onNSData that will let youencrypt a chunk of data that’s already in memory. This version creates a newNSData object with the encrypted contents of the originalNSData instance. If your data is already in memory,and you want an encrypted or decrypted version of it,then theNSData methods are the way to go. Here is an example of using encrypting anNSData object with AES:

 NSData *encryptedData = [ data AESEncryptWithPassphrase:  @" My secret password"   ]  ;

Pretty easy,huh? Okay,now,this is a symmetric block cypher,it is not public-key encryption,so if you store your passphrase as a string in your application (as opposed to making the user enter it or storing it in the keychain) then you’re giving somebody the ability to decrypt your encrypted application data,so just be forewarned.

Also,I make no warranties about how secure this is. As far as I know,AES-256 has not been broken yet,however I cannot say for certaint that there are no weaknesses in the AES implementation I’ve used. I don’t see any obvIoUs problems but I am not a cryptographer. I haven’t heard of any weaknesses in this particular implementation,but any use of this is completely at your own risk.

Here is a zip file containing the two categories and the AES implementation . Just add these to your Xcode project,include the appropriate headers,andencrypt away.

Oh,and,one more important thing: If you use this in an iPhone application that you plan to sell on the App Store,it may lengthen the review process,as you will have to declare that you are using encryption,and will likely have to create and upload aCCATS form and wait for Apple to review it before your app will go up for sale. Read the iTunes Connect Developer Guide for more information on CCATS and the process before deciding to use this in an iPhone application for sale,please.

UPDATE: Jim Dovey author of the terrificOutput iPhone App ,posted a category onNSMutableData in the comments to this post that uses the crypto libraries already available on the Mac and iPhone to do AES-256 encryption. According to Jim,this means you don’t need a CCATS form because Apple’s exporting the encryption code,not you,so check it out Thanks,Jim.

原文链接:https://www.f2er.com/sqlite/202977.html

猜你在找的Sqlite相关文章