Android, Releases

Cryptnos for Android 1.2.3 Released

May 12th, 2011 | Comment?

Just a quick note for everyone that Cryptnos for Android version 1.2.3 has been released. As usual, the recommended location to get the update is from the Android Market, but you can also “side load” Cryptnos by downloading it from the links provided here on the site.

This is a minor bug fix release. We recently received our first error report through the Market feedback mechanism. It was discovered that in certain situations, the import/export mechanism in Cryptnos may run out of available RAM. Ordinarily, this should never be an issue; Cryptnos export files are usually very small, mostly because the data itself is small but we also compress the data before running it through the encryption routine. I have personally never seen a Cryptnos export file that is more than a few kilobytes in size, and I have over 50 sites in my database. That said, it is theoretically possible for someone to accidentally (or even maliciously) try to import a file that is not a Cryptnos export file. If the file isn’t too large, Cryptnos would in general handle this well; it would produce an error message stating that the file was invalid. If, however, the invalid file exceeded the amount of available RAM, Cryptnos would try to load it and subsequently run out of memory, leading to a virtual machine error not normally caught by our usually thorough exception handling.

The primary cause of this problem was the fact that during import and export, Cryptnos had to hold the entire contents of both the encrypted and decrypted data in memory all at once. While there were checks in place to ensure that the file could not be larger than 2GB (certain API-dependent parts of the code relied on 32-bit integers), there was no check on the amount of available RAM. There aren’t any Android devices that currently have 2GB of RAM, but there are tons of devices that have as little as 256MB or even 128MB. If a user “accidentally” imported, say, a 600MB MPEG-4 movie, Cryptnos would dutifully attempt to open the file and decrypt it. Unfortunately, if the device only had 256MB of RAM and Cryptnos tried to allocate 1.2GB of RAM, that would result in an obvious crash.

With this release, we’ve made the following changes to the import/export handler to improve the situation:

  • While the import routines are still required to hold the entire decrypted data in memory (we don’t want to write that to persistent storage anywhere), they now only read a tiny bit of the encrypted data from the import file at a time. This buffer is the same size as the block size of the underlying AES cipher, meaning the import routines use a lot less memory than they did before, practically half. Unfortunately, this optimization cannot be applied to the export code because we don’t want to write the unencrypted intermediate data anywhere persistent; we have to hold it in memory at least until it’s encrypted, meaning that both the unencrypted and decrypted data must be in memory at the same time, at least for a brief time. Fortunately, this shouldn’t be nearly as big of a problem for exports as it would be for imports because we know how much data we’re dealing with. Imports are far less predictable, especially given the scenario with the video file described above.
  • Both the import and export routines now release memory objects much more quickly than they did before. We used to rely on the virtual machine’s garbage collector to clean up our mess, meaning our allocated objects could hang around for an unspecified amount of time after the import/export process is complete. We know explicitly deallocate large memory objects immediately after they are no longer needed, which should trigger the GC to free that memory sooner.
  • In addition to the 2GB file size check, we now explicitly test to see if there’s enough RAM available to encrypt or decrypt the data before we start the process. It it looks like there’s not enough memory available, the user receives an error “toast”; they’ll have to free up some memory or try to import/export a smaller subset of data. Unfortunately, there’s not much we can do to assist the user here besides warning them. If their import file is exceptionally large (highly unlikely but not impossible), they may need to export the sites from the other Cryptnos instance in smaller chunks and import each chunk independently. However, this should protect us from “importing” that 600MB video file and crashing the app.

During testing this fix, we also discovered another bug in the old platform-specific, version 1.0 export format importer. I’m not sure if the bug was introduced by the fix above or if it existed prior to that, but we’ve fixed it nonetheless. During the import of an old-format export file, we found that Cryptnos would successfully import the data but would report that the file was invalid. This was because there was an extra line at the bottom of the unencrypted data, resulting in an extra “invalid site” at the end. This likely wasn’t affecting very many people because we didn’t have many users back in the version 1.0 days (the new cross-platform format was introduced in 1.1), but we certainly don’t want anyone depending on those files to have problems.

Tags: , ,


You can skip to the end and leave a response. Pinging is currently not allowed.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

You must be logged in to post a comment.