Cryptofon

Welcome to the Cryptofon Project!

This project aims to standardize and reference-implement the Cryptofon Standard, which aims to provide narrowband voice, message and data exchange.

The following planned features set it apart from competing Standards:

• 100% open-source specification, including all it's components in reference implementation.
• not a single-vendor / single-provider solution (!!!)
• narrowband-centric: Only 2400 bit/s up- and downlink are required [this includes an FEC 3/4], which in theory will allow deployment on slow infrastructure such as V.32, CSD, X.25 and even Iridium.
• point-to-point - system: Conferencing and direct connections work transparently on the device.
• Integrateable into practically any existing communication network or system: fully agnostic to underlying infrastructure, enabling it's use in radio, packet- [by encapsulation] and/or line-oriented networks.

Competing Standards:

• Cryptofon - Development ceased after sole maintainer was murdered. Also it required ISDN lines to operate on.
• GSMK CryptoPhone - single vendor solution, not open-source / public specification. Requires > 4 kib/s up- and downlink for voice communications.
• SCIP - uses MELP / MELPe Vocoder and is de-facto restricted to the U.S.-Government. It suceeded STU-III.
• H.323 makes encryption optionally, and requires ISDN- or faster bandwiths.
• VoIP solutions may be easy to implement, but are hard to secure. While SRTP & ZRTP may offer sufficient transport security, they require a Gateway per design, which makes denying access and spying on users easy to achieve. Providers of Servers and Services may be forced to grant bulk and automatized access to it's core network and subscriber account data. Here's a good legal example. Needless to say that this has been exploited by governments.

Competing Software Solutions:

• Signal requires the Users to have a phone that is used to sent unencrypted verification codes to - which can be considered obviously unsafe, since it's relatively cheap and easy to attack. While it has open-sorced the code for server and clients, they rely on non-free code as well as do not support using own servers, making it a single-vendor & sigle-provier only software/service solution.
• Discord may offer anonymity, but suffers serious problems mostly caused by the fact that it is a single-vendor & single-provider solution.
• Mumble may offer perfect forward secrecy, but it still requires UDP/IP-connectivity at reasonable speed [ >64 kbit/s up- & downlink], which can't be guaranteed on artifically slowed mobile networks, which also suffer from having no net neutrality.