DekuSMS: an Android SMS app with end-to-end encryption and cloud forwarding

The README calls this a proof of concept, not a product

DekuSMS is described as an Android SMS app that is being developed as a proof of concept for secure SMS messaging, SMS image transmission and SMS to cloud communications. The README then explains why the app is awkward to use, and it is worth repeating that rather than glossing over it: the reason is that the app aims to be as customizable as possible, so users can point it at their own cloud servers instead of being tied to specific providers. That trade-off explains most of the rough edges in the rest of the documentation. The app is distributed through F-Droid and Google Play under the package name com.afkanerd.deku, the project is on master with a last push on 2026-10-18, and the repository is a Gradle project with app/, ci/, scripts/, docs/ and fastlane/ directories plus a docker_build.sh script at the root. For a security tool, read the design as an engineering prototype whose interfaces are still moving.

The handshake produces SK, then RK, then a key chain

Encryption only works if both ends are running DekuSMS as their default SMS app, because the app uses custom data structures for the handshake and the encryption, and those structures are not part of other SMS apps. The users are guided through a Diffie-Hellman key exchange, after which a secure key is generated and associated with the peer's phone number. The README describes 32 byte agreement keys, roughly 50 bytes to be transmitted by SMS, calling that the SK, and then states that the SK becomes the RK for the first messages sent, which begins what the documentation calls the KeyChains. The README points at the Signal double ratchet specification for the details of what happens next. The distinction matters for readers coming from a mainstream messenger: here the transport is the carrier network and messages are segmented SMS, so the key material has to fit inside a couple of SMS bodies, and each hop across the network has to carry the state needed to continue the chain.

Headers travel in the clear and cost an extra SMS

Every message has a public key attached to it along with other details, collectively called the headers in the README, and the document is explicit that the headers are not encrypted yet. That has a direct cost in message count. For every SMS you send, one additional SMS is added for the header, so a single segment body becomes two messages on the wire, and a two segment body becomes three. The README also notes that the size of a composed message differs from the size of the encrypted message, which is why the app needs a user interface that can show the real size before sending. Another limitation is on the receiving side. DekuSMS sends secure requests as data channel messages, which do not need an internet connection, and the README is blunt that most other SMS apps will simply discard messages arriving on that channel, especially on iPhones, so a recipient without DekuSMS will most likely see nothing at all. There is also a documented race condition right after the first key exchange, because a carrier may fail to deliver the genuine party's message on time, which leaves room for an impostor to appear first.

Incoming messages queue until your cloud endpoint answers

The second main feature forwards incoming SMS to a URL you choose, which is what turns the phone into a sensor for a backend. The README describes the delivery behaviour precisely: messages stay in the queue until the device has an active connection, and they stay queued when the server returns a status code in the 5xx range, so a server outage does not lose messages but does defer them. The device also shows the user what is being forwarded into the cloud. Three protocols are supported, HTTP(s), SFTP and SMTP, so the same phone can push to a webhook, drop a file on a server, or send mail. The payload is a JSON document with the message identity, thread, dates, type, segment count, subscription id, status, error code, read flag, an is_encrypted flag, the formatted date, the sender address, the text and a data field, and that shape is the contract your backend has to parse.

The same phone becomes an outbound SMS gateway over RabbitMQ

The third capability runs the other direction. You can transmit data from your cloud to your Android devices and use the phone as the SMS gateway that actually sends the message over the carrier network. The app ships with built-in configuration for RabbitMQ, aimed at technical users who want to run their own messaging queue from their own server, and the README shows the message structure as a JSON object with four fields:

{"sid":"", "id":"", "to":"", "text":""}

The sid is a special identifier you can put in the message yourself, the id is generated by the queue server and is used to acknowledge the message rather than to decide status, and the to field carries the recipient phone number, with the text holding the payload to send. That design puts DekuSMS in the role of a worker that consumes a queue and turns each item into a real SMS, which is a different job from a messaging app. The cost of that role is the carrier again: sending is bound by network rates, message segmentation and delivery timing rather than by the queue, so a backlog of long messages turns into a long tail of SMS traffic on the phone's plan.

Where the messages live: still the default SMS inbox

One storage decision has consequences for anyone trying to evaluate the security claims. The README states that all messages, including encrypted ones, are currently stored in the default SMS inbox, which means encrypted payloads are persisted outside the app's own database, and that switching between SMS apps keeps the inbox as it is. An upcoming feature would move encrypted messages to a custom database for users who want that, but it is described as upcoming rather than shipped. There is a second related gap. The users cannot know when their peer has deleted their secured keys, so messages will still arrive in encrypted form after keys are gone, and the eventual goal, which the README admits has not been programmed yet, is to detect that the peer has fallen back to plain text and continue in plain text accordingly. Until that exists, sending a plain message to a peer who still has your keys is pointless, since you have no way to signal the change.

GPL-3.0, frequent releases, and an interface still in flux

The project is released under GPL-3.0, and the code is developed in the open with release tags close together: 0.76.0 and 0.77.0 both on 2026-08-16, and 0.78.0 on 2026-10-11, with the last push on 2026-10-18. The repository also carries CODE_OF_CONDUCT.md, a Gemfile for the release tooling, and a scripts/ directory, and the README has dedicated sections on building and on reproducible builds, which tells you the project cares about being able to rebuild the same artefact. The GPL-3.0 terms matter in one specific place here. If you fork the app to add a provider or change the protocol, you inherit copyleft obligations for the distributed work, and any third-party client you build has to speak a protocol compatible with the one in the repository. That is not legal advice, but it is the reason the README invites discussion with other SMS app developers about a unified open source protocol for end-to-end encrypted SMS, starting with Android.

Editorial conclusion

Use DekuSMS if you are building or testing encrypted SMS over carrier data channels, or if you want your own phone to forward incoming SMS to a server you control and to act as a gateway for queued outbound messages. Do not adopt it as a daily driver, because the README states the technical functions are not user friendly, because both parties must run DekuSMS as the default SMS app, and because the per-message headers are not encrypted yet. Verify first that your recipients also use DekuSMS, decide which of HTTP, SFTP or SMTP you will forward to, and read the README note about the race condition right after the first key exchange before you rely on the handshake for anything sensitive.

Frequently asked questions

Official sources

1. dekusms/DekuSMS-Android on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases