Tempo Maintenance, Thursday July 18th at 10 PM EDT

2013-07-17 14:10:55 -0400

This Thursday night, July 18th at 10pm EDT, Tempo and other web systems will be temporarily unavailable while we perform critical patch updates to ensure the stability of our services.

This maintenance outage will also affect the Tempo API, the the Connect website, and the site for Codebook.

Down time could last up to 1 hour, however we hope it will be completed much more quickly. If you need to get in touch with us for any reason, please don’t hesitate.

SQLCipher for Android - Urgent Upgrade Required

2013-07-10 17:27:59 -0400

The latest release of SQLCipher for Android includes a high-priority fix to address a compatibility issue with an upcoming Android OS release. When the new Android version is released, most likely later this year, applications using older SQLCipher for Android versions may crash on first use of the library.

We have been working closely with Google to address the problem, which stems from changes to android::MemoryBase, a wrapper around the Android shared memory functions previously used in the native CursorWindow implementation. The new version of SQLCipher for Android eliminates the use of android::MemoryBase in CursorWindow in favor of allocated heap memory.

Google has confirmed that the latest version of SQLCipher for Android addresses the compatibility issue with the new Android OS version.

Since applications that continue to access the legacy shared memory function will break at some point in the future, Google has recently introduced a warning trigger on API usage in a recent AOSP commit [1].

As a result of this upcoming change, we strongly urge all developers using SQLCipher for Android to upgrade to the newest version. We do not have a specific release date from Google, so it’s important that applications update as soon as reasonably possible.

The latest SQLCipher for Android binaries can be found here [2].


SQLCipher 2.2.1 Release

2013-07-10 13:08:00 -0400

We would like to announce a patch release of SQLCipher. It includes the following:

  • Addresses a potential threading issue when copying the cipher provider.
  • General improvements to the lifecycle of the provider.
  • Applied a mutex around RAND_bytes for OpenSSL usage to prevent concurrent calls in applications that have not configured OpenSSL threading callbacks.

The latest source can be found here [1] along with new SQLCipher for Android binaries here [2].


SafeWallet Alternative: Migrating from SafeWallet to STRIP

2013-07-01 11:43:57 -0400

UPDATE Oct 10, 2013: We've made great progress, and we're opening the download links up below, the latest build of Convert to STRIP for Windows should be processing the SafeWallet XML files correctly now. Please give it a shot and let us know! -WG

UPDATE Oct 8, 2013: The latest versions of SafeWallet (3.0.x) are NOT compatible with our converter. We're working hard with a number of our customers and lots of sample data to resolve this as soon as we can, but it's turned out to be quite a bit more complex than anticipated. We will get it! But be advised that if you are planning to purchase STRIP and to use the converter specifically for SafeWallet data, it does not work right now. Please get in touch with us if you have any questions, and thanks for your patience! -W.Gray

One of the more popular password managers out there is SafeWallet. A few new customers have been checking out STRIP as an alternative after reading about our password manager and have asked us about how they might import their SafeWallet data directly into STRIP. On Friday we posted an updated version of our Convert to STRIP utility to add this new option for both Windows and OS X. Read on to see how it works.

Get STRIP Now »

Convert to STRIP for Windows »

Convert to STRIP for OS X »

Export your SafeWallet data

Launch SafeWallet, login to your wallet, and then select File -> Export, and a simple export wizard will appear allowing you to save a .XML file of your data anywhere on your computer.

Convert SafeWallet data

  • Download the STRIP Data converter onto your desktop and Unzip it. Double click the icon to run it.
  • Click "Source File" button and choose SafeWallet XML export file.
  • Click the Save As button and save strip.csv on the desktop.
  • Make sure the "SafeWallet XML" radio button is selected for Source Format.
  • Click "Run Conversion" to migrate the file to the Strip export format.

Verify your data

There is now a 'strip.csv' file on your Desktop. You can open it in a spreadsheet editor to check its contents (e.g. OpenOffice.org, Numbers, Excel), or open it in a simple text editor. It's a good idea to check the data over for accuracy before importing it into STRIP.

Note: if you decide to edit your CSV data before import, be sure to save the file as CSV data when done. Additionally, if your data contains international characters (e.g. ü, é, etc) do not attempt to edit the file in Excel, your best bet to preserve these characters correctly is to use the free Calc spreadsheet editor from OpenOffice.org.

Import into STRIP

Log into STRIP on your PC or Mac and choose the strip.csv file on your Desktop.

Once the import is complete you'll see all of your SafeWallet data right in STRIP! Once you've checked that everything looks okay in STRIP you should delete the two plaintext import/export files (remember to empty your trash, or even better, securely delete them).

SQLCipher 2.2.0 Release

2013-06-27 12:45:57 -0400

We would like to announce the release of SQLCipher 2.2.0. The follow highlights changes included in this release:

  • Configurable crypto providers including experimental support for CommonCrypto and LibTomCrypt
  • A change to the native CursorWindow to remove usage of private android::MemoryBase
  • Renaming of generated binaries from sqlite3 to sqlcipher
  • Based on SQLite version 3.7.17

We have renamed both the library and shell from sqlite3 to sqlcipher (e.g. previously libraries which have been named libsqlite3.so are now named libsqlcipher.so, and the command line tool is now called sqlcipher instead of sqlite3). As the use of SQLCipher grows, this change will aid in isolating conflicts from system installed versions of SQLite. We have also narrowed the usage of non-static interfaces within the source. Thanks to Hans-Christoph Steiner from the Guardian Project for contributing the patches he used to prep SQLCipher for Debian.

We are also introducing configurable crypto providers in this release. OpenSSL remains the default provider, but we have included experimental support for both the Apple CommonCrypto library and the open source LibTomCrypt library.

To support this change, we have added an additional configure flag called --with-crypto-lib. Currently, you can specify one of the following values: openssl, commoncrypto, libtomcrypt, or none for amalgamation builds. If this flag is not included at configure, OpenSSL is used by default.

An example of building SQLCipher with CommonCrypto follows:

./configure --enable-load-extension --enable-tempstore=yes \
--with-crypto-lib=commoncrypto \

Applications that are compiling in the SQLCipher amalgamation or using the Xcode project can experiment with Common Crypto support by removing the openssl-xcode sub project and link dependencies, defining SQLCIPHER_CRYPTO_CC (i.e. adding a -DSQLCIPHER_CRYPTO_CC compiler flag), and adding Security.framework to the link libraries for the project.

An example of building SQLCipher with LibTomCrypt follows:

./configure --enable-load-extension --enable-tempstore=yes \
--with-crypto-lib=libtomcrypt \
-I/Users/nparker/src/libtomcrypt-1.17/src/headers" \
LDFLAGS="-L/Users/nparker/src/libtomcrypt-1.17/ -ltomcrypt"

Please note that the LibTomCrypt implementation is still in the formative stages, and should not be used for any real production implementations at this time due to limited entropy in RNG seeding.

Following compilation, once a key has been provided to properly initialize a cipher context, you can verify which provider you are using by executing the following read-only PRAGMA:

PRAGMA cipher_provider;

Finally, this release includes a fix to the native CursorWindow that removes the usage of android::MemoryBase. This resolves an issue under an upcoming Android platform release that marks this API as private and causes a crash.

The latest source can be found here [1]. We've also prepared a binary package of SQLCipher for Android here [2]. Please take a look, try out the new library changes and give us your feedback - we welcome it! Thanks!