This is part 2 in my series on TextSecure. Go back to part 1, if you haven’t read it. The analysis took place at the end of february 2014, using revision 5a62856e (current master at that time).

This part will cover basic project dependencies. The dependencies are important, because they will tell us, what code makes up our project. In projects of this size, there’s usually a nice portion that’s not actually written by the project authors themselves.

Dependency Tree

TextSecure builds from these separate parts:

• The TextSecure Client itself (From the TextSecure Repository itself. The client that you will actually see on screen)
• A TextSecure Library (From the TextSecure Repository itself. Contains crypto and integration classes)
  • Protocol Buffer Java API (version 2.4.1, from google, common data structure format)
  • Spongy Castle Crypto API (version 1.47.0.2, open source third party library, used for cryptography)
  • libphonenumber (version 5.3, from google, formats international phone numbers)
  • gson (version 2.2.4, WhisperSystems jarjar-repacked this version, based on googles 2.2.4 version.)
  • armeabi.jar (Native curve22519 implementation, provided as compiled armeabi.jar with the project. The source is said to be included in the library/jni directory.)
• ActionBarSherlock (version 4.4.0, very common open source third party library that is mainly used for those nifty top navigation bars)
• Android Support v4 (version 19.0.1, from google, extremely common Google Library that helps with backwards compatibility)
• Cloud Messaging (version 1.0.2, from google, i haven’t seen it in other projects, but i guess that’s due to the project nature)

How do i know all this? Well, it’s right here in the build.gradle file along with the library’s gradle file. This file “knows” how to build the project with a tool called gradle.

As you can see already, there’s quite a lot going into a seemingly simple messenger. So far, i count 10 Seperate parts, made by WhisperSystems, Google, Jake Wharton, Roberto Tyley, and possibly another party (armeabi.jar). I will update this post, once i tracked down the remaining sources (see supplemental below).

To be reasonably sure that TextSecure is not compromised, we’d have to analyse parts by WhisperSystems in great detail. To be really sure that TextSecure is secure, this would not be enough. We’d have to analyse all the parts. A really sneaky attacker might bring malicious code into a third party library. Yes, it’s a long shot – but a very possible one. And then, there’s the operating system of the computer which built the app, the build system itself, the operating system of the phone in question… you get the idea. Security is hard.

For now, we’ll concentrate on the WhisperSystems parts. My focus is on the “are their claims sincere” and not so much the “is TextSecure absolutely secure”.

[Supplemental: After asking on the bugtracker, i was told where to find the sources for gson and armeabi.jar. I incorporated the info into this post, it is therefore no longer marked as “could not track down source”. I will now start digging into the source code itself.]