Encrypted calls - Cryptophone.de protocol

Mikko Rauhala mjrauhal at cc.helsinki.fi
Fri Aug 22 19:07:28 CEST 2008


There has been some occasional interest in support for encrypted
phonecalls on OpenMoko. While I don't probably have the time to majorly
contribute to implementing said feature, the matter interests me and
therefore a couple of weeks ago I took it upon myself to liaise a bit
with GSMK/cryptophone.de, a German encrypted GSM manufacturer. Their CTO
Frank Rieger was on holidays, but got back to me recently, in a rather
helpful tone.

The cryptophone.de phones use GSM data calls to transmit encrypted voice
streams in either direction. This is the most generic suitable method
for the Freerunner as well - GPRS lacks the quality of service for
decent voip (push-to-talk may be okay), and wifi hotspots aren't always
around (plus they don't make you available at your GSM number).

Yes, GSM data calls cost per minute and are slow, but they have
guaranteed network resources, a decent round-trip, and still enough
bandwidth for highly compressed voice streams. As for the cost, it isn't
necessarily higher than for voice calls (obviously, this is locale- and
operator-dependent and some operators reportedly make you pay through
the nose, but that's the way it goes).

It would make sense in many ways (security, interoperability, installed
base) to use a somewhat proven and already deployed protocol, even if
not an open standard (there being none for this purpose I'm aware of).
(Disclaimer: I have not personally reviewed the cp.de protocol for
security nor am I qualified to do so.)

Cryptophone.de makes it clear on their site that their software is
non-free and the source is provided for security review purposes only.
However, they do also state that they have no problem with somebody else
doing their own implementation of the protocol from the spec.

I tried in vein to find the protocol documentation on their pages, but
after they got back to me, it turns out it's in the source package, in
the docs subdirectory. I had been careful not to download that, not to
give any impression of unlicensed copying of code. However, if that's
what they point to when I specifically ask for specs for the purpose of
reimplementation, it should be okay if one doesn't actually cutpaste the
code too (personally I wouldn't even look at it, not to inadvertently
make similar solutions and cause trouble onwards). You do need to accept
a license for the source code and binaries to download the whole
package. The download is at the bottom left of

Frank did also mention that they have done some protocol changes "that
have been becoming necessary over time"; he expects to have an updated
and expanded documentation available by November, and promised to get
back to me when that happens. The current docs should probably provide a
decent starting point though.

(Also of potential interest to some, GSMK are apparently keeping an eye
on Linux-based phone development, OpenMoko included, and a product from
them wouldn't apparently be out of the question if the market appears.)

Soo. Hopefully this information proves useful to some more industrious
members of the community, in paving the way for interoperable encrypted
calls on OpenMoko.

Mikko Rauhala   - mjr at iki.fi     - <URL:http://www.iki.fi/mjr/>
Transhumanist   - WTA member     - <URL:http://www.transhumanism.org/>
Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>

More information about the devel mailing list