I believe it was a couple of years ago that I first met Nate Freitas at No↔Space co-working here in Brooklyn (née The Change You Want To See). He was working on ideas to help enable and protect communications amongst fellow activists, and I took an instant liking to him—this was a trouble maker! I mentioned our SQLCipher project to him, it was still pretty new in 2008, and he was immediately interested in being able to use it in Android applications. Since then he’s gone on to help found the Guardian Project, which aims to arm and protect mobile devices against unwanted surveillance and intrusion. Recently, he got back in touch with some big news:

After some major breakthroughs during last week’s development sprint, we’re extremely excited to announce SQLCipher for Android, Developer Preview r1.

SQLCipher is already on mobile devices on other platforms, but this is the first time it’s been made easily accessible for an Android developer, bringing compatibility with the native SQLite interfaces provided by Android. I’d say that probably makes it even easier to work with on Android than on iOS, as it closely integrates cursors with views (in Cocoa-land, you can’t just plug SQLCipher into Core Data, you have to role your own data management classes). Our teammate Erik was able to easily drop it into a sample Android project and get it working in no time.

In an environment where mobile data privacy is increasingly in the headlines, this project will make it easier than ever for mobile developers to properly secure their local application data, and in turn better protect the privacy of their users. The data stored by Android apps protected by this type of encryption will be less vulnerable to access by malicious apps, protected in case of device loss or theft, and highly resistant to mobile data forensics tools that are increasingly used to mass copy a mobile device during routine traffic stops.

Big ups to Hans-Christian Lee of Guardian who did brilliant work achieving this high level of integration with the Android platform. Please check out the Guardian Project and their apps, especially if you own an Android device. If you’re a hacker, give the developer preview a shot, and consider helping them hack on some seriously cool software.

Recently, we had a query on the SQLCipher Users’ mailing list inquiring about the performance of a LIKE query, where the user was wondering if SQLCipher’s encryption engine was responsible for poor performance he was seeing in his code. “It depends,” is the cheapest and most accurate answer we could give without seeing his query and the EXPLAIN plan generated by SQLite (no index, for instance, could lead to a full table scan, thus requiring every page to be decrypted). What we do know is that performance of SQLCipher compared to SQLite is really pretty good, and certainly good enough for our needs as application developers.

If you’ve been wondering what kind of performance hit you can expect using SQLCipher as compared to vanilla-SQLite, we’ve published a new tool to help you get an idea. In the end,EXPLAIN and EXPLAIN QUERY PLAN cannot be replaced, but for a quick side-by-side reference to see that we’ve done a half-decent job, check out Stephen’s SQLCipherSpeed. It’s an iPhone OS project that rips through the various SQLite speed tests. I ran it on my crunky iPhone 3G and the results were about what I expected, and pretty interesting:

In this next one, note that there is no performance impact for 2500 selects on an index.

You’re highly encourage to check out the code yourself, and to fork it. It would be really cool if someone added an action button to the results screen to email the data off-device. More tests wouldn’t hurt either.

We will be having maintenance for the various sites Zetetic runs includingTempo on May 3rd, 2011 at 10pm PST toperform system upgrades. The maintenance window should last no more than 1hour.

We will be adding a few new features to Tempo, and a new plan, so stay tuned!

Thank you for your patience.

Apple has informed us that Strip 1.5.2 has been approved, so we’re releasing it this morning, it should be available in the iTunes App Store by the time this post goes live. As previously communicated, this release removes the In-App upgrading service and reverts Strip to a paid-only application. All existing customers should upgrade, it’s free. Please let us know if you see any issues.

Updated: 6/6/2012 This blog post is out of date, and the software referenced in it, Strip Sync, has been discontinued in favor of Strip for Windows and Strip for OS X. For more information on our data export format, please see this newer blog post.

Strip Sync is a free tool we distribute for customers of our password manager, Strip. It’s a kind of hold-over until we’ve got a proper desktop port of Strip that provides some basic but necessary capabilities, in particular the ability to bulk import your data (say, from another program or source), and to export your data (so you can print a hard copy to store in a safe, or so you can move off Strip someday).

The import and export files are CSV files. That is, plain-text files structured in a particular way, that can be opened in a spreadsheet programs like Excel. A good many people out there are familiar with spreadsheet programs, but Excel has some issues when it comes to opening a CSV file and displaying the data correctly:

• UTF-8 is not supported when opening a CSV, ASCII is assumed, so international characters turn into garbage.
• Leading zeros on numbers like PINs and postal codes are lopped off.

Our international customers, being quite fond of their umlauts, have written us a few times about the first problem, one that MSFT does not appear poised to fix this century. The second issue can be a real nuisance if you have a column like “Zip Code”. Excel always assumes such data is a Number (even if it’s wrapped in double-quotes), and if you format the column as Text after you’ve already opened it, the zeros have already been lopped off. Obviously, this isn’t a show-stopper, but it’s not appropriate for printing a hard copy of your secret keys for safe storage.

Looking for another work-around, I tried using Excel’s “Get External Data” wizard to import the text from a CSV, but it doesn’t respect line-breaks in quoted text fields, so even though you can mark your Zip Code column as text on the way in, the rest of your spreadsheet gets wildly munged by any line-breaks you might have in a note field.

This morning I fired up Open Office.org for the first time in a long while to see how it’s spreadsheet program Calc handles this, and it’s just the thing for our customers. Did I mention that it’s free? Here’s how it went down: I exported from Strip Sync, I right-clicked on the file, selected OpenOffice.org, tweaked some settings on the dialog panel that came up, and I was in business.

Step-by-step

First, right-click (or control-click) on the export file, and instead of opening it with Excel, go with OpenOffice.org.

When the Text Import dialog pops up, take a look at the Separator Options: the only one you should check off is Comma. Make sure Text Delimiter is set to straight double-quote (“).

Next take a close look at the Fields listing, and scroll over to any column that contains numeric data that you don’t want munged, e.g. PIN, or Zip Code, etc. Select the column header, and choose Text from the Column Type pop-up to ensure that leading zeros won’t be lopped off.

Then open it up, you’re all set! You get to keep those leading zeros.

From here you can manipulate and format the spreadsheet for printing however you like, or you can export it to a native Excel workbook format if you prefer to work in Excel. Excel does support UTF-8 characters, just not when opening a CSV file.