Security: what it protects and what it doesn't

Last reviewed: 23 September 2026.

An app that says "end-to-end encryption" and doesn't say where that encryption ends is selling a guarantee it can't keep. Starting with this: the full guarantee is provided by the installed application; in the browser, the program that encrypts is downloaded from our server every time you open it. This page exists so that you can decide what to say on T-kall knowing where things stand.

What it does protect

• The content of your messages. It is encrypted on your device and decrypted on the other person's. The server stores sealed envelopes and does not have the keys to open them.
• The title and notes of your appointments. A calendar says a great deal about a person ("meeting with the lawyer"), so they are encrypted too. The price: the 15-minute reminder can't tell you which appointment it is.
• Calls between TWO people. Those made with a chat's call and video call buttons: audio and video travel encrypted (DTLS-SRTP) directly between the two devices whenever the network allows it. When it doesn't, a relay server passes the already-encrypted traffic along: it relays without being able to listen. Note: a video appointment, a "Meet now" meeting and a chat's group call button always go through the rooms server, even if there are only two of you: for security purposes they are group calls. Group calls are also encrypted on your device as of version 0.4.0, with a caveat and some data that server does see, all in their own section (point 8).
• Passwords. They are stored as an Argon2id hash, never in the clear. Not even we can read them.
• Traffic in transit. Everything goes over TLS. The app is compiled so that it cannot talk to anyone over http://: if someone pointed it at an unencrypted server, it would stop working instead of sending messages in the clear without warning.
• That no one slips you a fake device. Each account publishes a signed list of its devices, and those lists go into an append-only log. Your device demands proof that your contact's list is in that log and watches yours too: if someone published a list in your name that you didn't sign, your own phone detects it. Messages carry inside them which version of the log the sender saw, so two people talking to each other compare it without meaning to. Since August 2026; the limit that remains is in point 1 below.
• Private keys never leave the device. Android's backup is deliberately disabled, so they don't end up uploaded to Google's cloud.

What it does not protect (yet)

1. We publish the key log ourselves

Until August 2026 this said that the first contact with someone new couldn't be verified, and that closing that gap was "a big project". That project is done and what it does is described above. What remains open is smaller, but it isn't zero.

That log doesn't prevent the attack: it makes it detectable. A malicious server can publish a fake key; what it can no longer do is publish it in secret, because doing so forces it to publish two incompatible versions of the same story and that shows. It is the same deal that has underpinned the certificates of the entire web for a decade.

And it's our own server that publishes it. As long as the log's roots aren't copied to an independent site, whoever checks them and whoever issues them are the same house. Detecting the contradiction still works between two people talking to each other —that doesn't depend on us—, but third-party verification doesn't exist yet.

What closes it: publishing the roots externally, where anyone can audit them without having an account. In the meantime, comparing the safety number over another channel is still the strongest check there is, because it's the only one that doesn't rely on our infrastructure.

2. Chats change keys with every message; healing from a theft, not yet

Each chat message travels with its own key, derived from a fresh agreement per message (X3DH, the same first step Signal uses). That covers one specific attack, and it is worth saying exactly which one and which one it doesn't:

• Each message has its own key, and the previous one is destroyed. Someone who saves your encrypted messages today —a copy of the database, a traffic dump— and months later obtains your device's key opens nothing from before with that key (what they would take is whatever remains in the device's local store —the already-decrypted text and a second cache holding each message's key, with the same cap—: that's the point below). With a caveat that has to be stated: that deletion is immediate as long as single-use prekeys remain, and if the batch runs out it falls back to the signed prekey, where the protection arrives when it is rotated —up to 37 days later.

And what still isn't covered, which matters just as much:

• The conversation doesn't heal itself. If someone does steal a device's key, it keeps working for them: there is no clean exchange that invalidates it. The double ratchet that closes this is written and the app knows how to read what it emits, but it's switched off today: when a session fell out of sync it left pairs of messages unreadable forever, and permanent data loss is worse than the window it was closing. It will be switched on when session recovery is done and reviewed. This page once said this was already solved: it was true for a few weeks in August 2026 and stopped being true when it was switched off. We correct it here rather than leave it promised.
• If your phone is taken from you, the recent stuff is still exposed —and now it's the text. Since 28 August 2026 the app does store the already-decrypted messages on the phone —decrypt the first time it's shown and read from there, like Signal or WhatsApp— instead of decrypting the whole thread again each time you open a chat. It's wrapped with a local key that can't be exported from the device: anyone who copies the store without the key reads nothing, and a flaw in the web part can't copy the key either —what such a flaw could do is use it from inside the app and read the stored text, message by message—. It's still limited to 400 days or 20,000 messages (counted from when that device stored it, and pruned at startup); but anyone who takes the unlocked device and dumps its storage takes the text, not just the keys to obtain it. A local password to encrypt it at rest is pending. None of this protects against someone holding your phone in their hand.
• Appointments don't. The title and notes of an appointment still use the previous scheme: they are encrypted today to be delivered weeks later, and that lead time doesn't fit a scheme that changes keys at every step. Treat them as the weakest link.
• Only if both people have updated. If the sender —or any of the receiving devices— is on an earlier version, that message travels with the old protection. The app flags it with an amber notice ("Sent without forward secrecy (old format)") when someone who was already writing to you with the new protection does so again without it —including on your own messages—, unless that message already carries a red notice, which takes precedence; if that person has never updated, there is nothing to compare against and no notice appears.

Half of this section —that each message carries its own key— is done and in use. The other half —that the conversation heals from a theft— requires the ratchet switched on, and switching it on first requires session recovery: it's the biggest outstanding work on this page. And neither of the two touches point 1 —the first contact—: they serve to protect a conversation, not to prove to you who you are having it with.

3. The server sees everything that isn't encrypted

This does not travel encrypted, and the server sees the whole of it:

• who talks to whom, and when;
• what time each appointment is and how long it lasts, and who is invited to what;
• the emails and phone numbers of every account (they are the identity: they have to be in the clear so that people can find you);
• membership in teams, channels and organizations;
• in group calls, meetings and video appointments, who joins each room, when they join and leave, and the meeting's name if it was given one (the rooms server sees it: point 8);
• the IP addresses of each connection.

That's the metadata, and for many people it is more revealing than the content: two people talking every day at three in the morning says quite a lot without reading a single word. Signal tackles this with techniques we don't have yet.

4. There is no backup, on purpose

Private keys live only on the device and Android's backup is disabled. The price has to be stated up front and not after the fact: when you change phones or reinstall, the history and the keys are lost. There is no way to recover it.

The correct alternative is an encrypted backup with a key that only you hold, like WhatsApp's encrypted backup. It isn't built.

5. The app is a web page inside a container

T-kall runs in the system WebView; it is not a native client. The security of the encryption therefore depends on the security of that WebView, which Google updates and not us. It's mitigated (no cleartext traffic, no backups, with a content policy), but it's an attack surface that Signal or Threema don't have because their clients are native.

6. Fingerprint lock protects less than it seems

Biometric lock stops someone who picks up your unlocked phone from opening the app and reading. That's what it does, and it's fine. What it does not do is encrypt anything: anyone with access to the device's storage (with root, with a forensic dump or with an Android flaw) pulls out the keys —and, since 28 August 2026, the text of messages up to 400 days old— without going through the fingerprint. It's a door, not a safe.

8. Group calls, encrypted on your device (with one caveat)

A call between two people made with a chat's call or video call buttons goes straight from one device to the other. A group call needs a server to gather and distribute everyone's audio and video, and video appointments and "Meet now" meetings also go through that same rooms server, even if there are only two of you in them. As of version 0.4.0 that audio and video are encrypted on your device (SFrame, with key distribution over the already-encrypted channel) and our rooms server only relays them, without being able to see or hear them. The same holds for a meeting joined by link even when the person joining is from another organization: the key is distributed only among those in that meeting.

The caveat. A call is encrypted this way only when all of those present are on a recent version. If someone joins on an old version, that call drops on its own to encryption only as far as the server while that person is there —and the app tells you, with the room indicator— so as not to leave anyone unable to see or hear. While the fleet catches up this will happen often; as everyone updates, it will stop happening. If what you're going to say can't pass through our server in that case, use the two-person call with a chat's call or video call buttons (the group call button goes through the rooms server).

What the rooms server does see, whether the call is encrypted or not: who joins (their account's identifier and their display name), from what IP address, into which room —by its technical identifier, not by the channel's name—, when each person joins and leaves, what each person publishes (microphone, camera or screen share) and whether it is muted, technical data about the connection (the version of the calling software and the browser or system they connect from), whether each device's version can encrypt the room, and the technical "I can't decrypt you" notices that the devices send each other. And the meeting's name, if the host gives it one in "Meet now": it is shared over the room's data channel, which is not encrypted on the device —only the audio and video are—, so that server can read it. If the name is sensitive, leave it out. The title of a video appointment does not travel that way: it stays encrypted. And no call is recorded.

And where it is. The rooms server is a different machine from the one that stores the messages, contracted from Hostinger in a data center in the United States. What it sees of each call therefore leaves the European Economic Area (Privacy, sections 6.2 and 7).

9. No outside party has audited it

All of T-kall's security analysis we've done ourselves. Signal, WhatsApp, Threema and Wire have published external audits and protocols reviewed by academia over years. A cryptographic flaw doesn't show while things are working: the app runs perfectly and the messages read the same. That's why an in-house review, however careful, is no substitute for an external one.

Summary

What you can do

• Compare the safety number of a new conversation over another channel before sharing anything sensitive. It's the only thing that closes point 1 today.
• Compare the call code out loud at the start. If you both read the same one, no one is in the middle.
• Review your devices from time to time and revoke any you don't recognize. A new device needs the approval of one that is already approved.
• Consider the history lost when you change phones: there is no restore today.

Reporting a flaw

If you find a security problem, tell us before making it public and it gives us time to fix it: angel@engravitysigns.com. Write "Fallo de seguridad" in the subject.

We have no bug-bounty program or disclosure agreement to offer you, and we'd rather say so than imply otherwise. What we do do: reply, fix, and give you whatever credit you want —or none, if you prefer it that way—.