Two methods to encrypt the SQLite Database

One is to use sqlcipher

Need to store sensitive information in your app? Sqlcipher

Extends SQLite enabling transparent encryption and decryption of data using AES. Its Source

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 wowould and all of the Crypto is handled
Transparently.

 

Sqlcipher's author, Stephen Lombardo of zetetic

, Has also released cryptographically secure file I/O

A library that supports random access file IO on encrypted files.

 

Another

Strong Encryption Cocoa
/ Cocoa
Touch


AES

Is a strong encryption standard that has mostly replaced the aging DES

Standard.
AES is widely used and fairly secure encryption Mechanic (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
Encryption and the more processing power it takes Encrypt
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 a public 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 on nsfilemanager
, And allows youEncrypt
A
File in the filesystem. It takes a file at a particle 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.
CATEGORY adds two methods to nsfilemanager
,
One for encrypting, the other for decrypting. These methods are
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 on nsfilemanager
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 on nsdata
That will let youEncrypt
A chunk of data that's already in memory. This version creates a new nsdata
Object with the encrypted contents of the original nsdata
Instance. If your data is already in memory, and you want an encrypted or decrypted version of it, then the nsdata
Methods are the way to go. Here is an example of using encrypting an nsdata
Object with AES:

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

Pretty easy, huh? Okay, now, this is a pair Ric 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
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'theard of any weaknesses in this particle implementation,
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 operate 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 a ccats

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 terrifle IC output iPhone app

, Posted a category on nsmutabledata
In
The comments to this post that uses the crypto libraries already
Available on the Mac and the iPhone to do AES-256 encryption. According
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.