Great idea, but pls don't roll your own crypto

[n8fr8]

Really glad to see the CM team take a stronger interest in building in security directly into the firmware. We (@guardianproject) just want to do our part to help you avoid headaches down the road.

Both Moxie's TextSecure app and our Gibberbot app (as well as Xabber and Beem) provide proven variations on end-to-end crypto based on the well known Off-the-Record Messaging Protocol. I realize you aren't building a standard XMPP solution here, but the approach to messaging crypto should be the same.

http://www.cypherpunks.ca/otr/Protocol-v3-4.0.0.html

You can find the clean Xabber OTR4J library here:
https://github.com/redsolution/otr4j

TextSecure is here:
https://github.com/WhisperSystems/TextSecure

[koush]

Yup, I certainly don't want to reinvent the wheel here.

I'm not a crypto expert by any means-- this approach was a first stab at building a frictionless encrypted communication client and get a discussion going within the community.

I'm well aware of TextSecure. :) I actually had a call with @moxie0 earlier this week to discuss exactly this. He's excited about the project as a lot of our interests align, and I am looking forward to collaborating further with him.

We'd talked about dropping TextSecure wholesale into CyanogenMod. Couple issues: it's GPL at the moment, and at CM we prefer it be Apache/AOSP licensed. Twitter currently holds the copyright to TextSecure, so I didn't want to start copying code out of it (or even look at it) and potentially cause licensing issues later. And we've tweaked a lot of stuff in the CM stock messenging app that would need to be ported over to TextSecure. Not to mention, it leaves third party apps (which Android users love) out to dry.

In any case I plan to work with @moxie0 and incorporate his feedback and have some level of compatibility with TextSecure.

I do want to mention a point of note: the project focus here is not end-all security. There are obvious trade-offs there for the end user. 100% security focused projects will result in the user suffering.

[n8fr8]

Definitely - I really just mean that when you get to that part when you are figuring out how to exchange keys and establish an encrypted session tunneled inside of GCM, there is already a really well established model of how to do that (OTR). It is fast and simple, can be nearly transparent to the user that it is happening at all. If they care to take further steps to verify the connection they can, but it is not required for most users.

[ioerror]

I'd very much like to encourage you to look at the OTR project's protocol: http://www.cypherpunks.ca/otr/Protocol-v3-4.0.0.html - I found the Facebook post ( https://www.facebook.com/CyanogenMod/posts/10153047439985425 ) where the PGP model was mentioned. I think the OTR model is actually the right model - it gives us forward secrecy, it works in band, it allows for verification, etc. This is basically what TextSecure has done - though they made a few changes to the protocol that I think you wouldn't need to do.

I totally think working with @n8fr8 and @moxie0 is the right path forward. Thank you for working on these issues!

[dalb8]

So, this is Apache licensed except for the bits that are proprietary i.e Google Play Services library… This is the Google Android SDK license type — not the AOSP type. With the introduction of libraries like this and Google Analytics the project is diverging from the AOSP philosophy.

[koush]

@dalb8 there's no license on this yet. it will be contributed to the CM project under whatever license they want, which will probably be Apache. http://source.android.com/source/licenses.html

I'm also going to not have full dependence on GCM, and plan to use the SMS transport as a failover option. Having already chatted with @cyanogen, he has no issues using Google SDKs if the need justifies it. We just don't want complete reliance.

[koush]

added apache

[koush]

@ioerror agreed that OTR is the right model here. forward secrecy is necessary.

need help with the crypto part?