Latchat

Teknis

Cara kerja Latchat

Apa yang sebenarnya dilakukan aplikasi ini terhadap pesan Anda, apa yang bisa Anda periksa sendiri, dan apa yang tetap tidak terbukti dari semuanya itu.

Halaman ini adalah penjelasan, bukan bukti. Kode sumber Latchat tidak dipublikasikan, dan belum ada pihak luar mana pun yang mengauditnya.

Yang bisa dilakukan halaman seperti ini hanyalah menjelaskan secara cukup rinci sehingga bisa ketahuan salah kalau memang salah. Jadi setiap bagian di bawah ini ditutup dengan apa yang tidak dibuktikannya, dan bagian itu ditulis dengan sungguh-sungguh.

1. Enkripsi

Klaimnya: isi pesan dienkripsi ujung ke ujung, dan server kami tidak memegang kunci yang bisa membukanya.

Cara kerjanya

Setiap pesan disegel dengan XChaCha20-Poly1305 sebelum meninggalkan ponsel Anda, memakai kunci yang dibuat khusus untuk pesan itu saja. Nomor pesan dan penanda rute ikut diautentikasi bersamanya, jadi perantara yang mengubahnya akan merusak segelnya dan pesannya ditolak.

Kunci-kunci itu diturunkan dari sebuah kunci grup yang dihitung sendiri oleh setiap anggota dan tidak dipegang oleh server mana pun. Setiap pengirim punya rantai kuncinya sendiri, dan setiap pesan punya kuncinya sendiri, yang diambil dari nomor urut pengirimnya. Nonce-nya juga diturunkan dari nomor yang sama, bukan diacak, supaya nonce yang terulang berarti nomor urut yang terulang, dan itu adalah sesuatu yang bisa dilihat dan ditolak oleh ponsel lain.

Identitas memakai Ed25519, pertukaran kunci memakai X25519, dan BLAKE2b dipakai untuk menurunkan kunci serta sebagai MAC grup. Undangan yang dikirim lewat tautan disegel dengan kunci dari angka rahasia yang diregangkan memakai Argon2id, 256 MiB memori dan tiga putaran, dan itulah sebabnya ponsel butuh beberapa detik untuk membukanya. Semuanya berasal dari libsodium, dikunci pada satu versi dengan checksum di dalam proses build. Tidak ada satu pun algoritma yang dibuat sendiri di sini.

Grup tidak memakai double ratchet, dan itu disengaja. Pesan di jaringan mesh bisa datang tidak berurutan dan terlambat berjam-jam; ratchet akan menghabiskan waktunya menyimpan kunci untuk pesan yang masih ada di ponsel orang lain di seberang lembah. Satu kunci per epoch membuka pesan mana pun dari epoch itu, kapan pun ia tiba. Ongkosnya disebutkan terus terang: tidak ada forward secrecy di dalam satu epoch. Yang benar-benar mengakhiri akses seseorang adalah mengeluarkannya dari grup, yang mengganti kunci grupnya.

Selain disegel, setiap pesan juga ditandatangani dengan kunci pribadi pengirimnya. Segel grup membuktikan sebuah pesan datang dari dalam grup; tanda tangan itulah yang membuktikan anggota mana yang mengirimnya. Tanpa itu, sesama anggota bisa menaruh nama orang lain di sebuah pesan, karena semua anggota menurunkan kunci grup yang sama.

Yang bisa Anda periksa sendiri

Pantau lalu lintas jaringan ponsel yang menjalankan Latchat. Ia hanya berbicara dengan dua alamat: layanan notifikasi Google, dan relay.latch.chat. Yang menyeberang ke perantara itu adalah amplop tersegel.

Baca kebijakan privasi. Di sana tertulis dalam bentuk tabel apa saja yang memang terlihat oleh server perantara, dan itu bukan nol: pola siapa berbicara dengan siapa, kapan, dan seberapa besar.

Yang tidak dibuktikan oleh bagian ini

  • Byte tersegel di server perantara membuktikan bahwa server itu menerima ciphertext. Itu tidak membuktikan bahwa aplikasinya tidak menyimpan salinan kunci di tempat lain. Hanya kode sumbernya yang bisa menjawab itu, dan kode sumbernya tidak publik.
  • Belum ada audit dari pihak ketiga. Tidak ada seorang pun di luar proyek ini yang pernah memeriksa kodenya.
  • Tanda tangan membuktikan siapa yang menulis sebuah pesan. Ia tidak membuktikan bahwa isinya benar. Sesama anggota grup tetap bisa berbohong atas namanya sendiri, dan itu bukan sesuatu yang bisa diselesaikan oleh aplikasi mana pun.
  • Tidak ada forward secrecy di dalam satu epoch: siapa pun yang berhasil mengambil kunci epoch dari sebuah ponsel bisa membuka pesan-pesan epoch itu yang masih tersimpan.

2. Jalurnya: internet dulu, Bluetooth kalau tidak ada

Klaimnya: internet adalah jalur biasanya, Bluetooth adalah jalur cadangannya, dan tidak satu pun dari keduanya dijanjikan pasti sampai.

Cara kerjanya

Kalau ada koneksi, pesan dititipkan ke sebuah server perantara kecil milik grup Anda. Server itu menyimpan amplop tersegel paling lama 24 jam dan membangunkan ponsel yang sedang tidur dengan notifikasi kosong, yang isinya benar-benar tidak ada apa-apa selain "ada sesuatu, bangun".

Kalau tidak ada koneksi, ponsel-ponsel di dalam grup saling terhubung langsung lewat Bluetooth dan saling mengoper apa yang sedang mereka bawa. Sebuah pesan berhenti berjalan ketika sudah sampai ke semua orang, atau ketika jatah waktunya 24 jam habis.

Kedua jalur dipakai sekaligus, bukan bergantian. Dan tidak satu pun dijanjikan: aplikasi ini tidak pernah menampilkan status terkirim yang tidak bisa dibuktikannya.

Yang bisa Anda periksa sendiri

Ini bagian yang benar-benar bisa Anda buktikan sendiri, dan cuma butuh lima menit serta dua ponsel yang ada di grup yang sama.

Satu. Nyalakan mode pesawat di kedua ponsel, lalu hidupkan lagi Bluetooth saja. Tidak ada internet dan tidak ada sinyal seluler. Kirim pesan. Pesannya sampai.

Dua. Matikan Bluetooth di kedua ponsel dan hidupkan wifi. Kirim pesan. Pesannya juga sampai.

Soal jaraknya, ini yang terukur, satu sesi di luar ruangan pada 13 Agustus 2026 dengan dua ponsel: sekitar 30 m untuk sambungan yang masih sanggup membawa pesan, dan 51 sampai 55 m sebelum sebuah ponsel berhenti terdeteksi sama sekali. Dua angka itu berbeda jauh, dan yang dipakai di halaman depan adalah yang lebih kecil, karena terdeteksi tidak sama dengan bisa berkirim pesan.

Yang tidak dibuktikan oleh bagian ini

  • Angka jaraknya berasal dari satu sesi, satu pasang ponsel, di luar ruangan, layar menyala. Di dalam ruangan belum pernah diukur sama sekali.
  • Tidak ada jalur yang menjamin pesan sampai. Notifikasi ke ponsel Android yang sedang tidur pernah terukur tertunda dengan median sekitar 4.392 detik pada prioritas biasa. Itu lebih dari satu jam, dan itu ukuran nyata, bukan perkiraan.
  • Kalau semua orang di luar jangkauan Bluetooth dan tidak ada koneksi, pesannya menunggu. Ia tidak hilang, tapi juga tidak sampai, dan setelah 24 jam ia berhenti dibawa.

3. Apa yang tidak ada di dalam aplikasinya

Klaimnya: tidak ada analitik, tidak ada pelapor kerusakan, tidak ada SDK iklan, dan tidak ada pelacak. Satu pengecualian, dan hanya satu: Firebase Cloud Messaging, yang dipakai untuk membangunkan ponsel yang sedang tidur karena di Android tidak ada penggantinya.

Yang bisa Anda periksa sendiri

Sebuah berkas APK adalah arsip zip. Bukalah, lalu baca nama-nama kelas di dalam berkas .dex nya. Kalau ada SDK analitik di dalamnya, namanya ada di situ.

Pemeriksaan itu dilakukan pada 25 Agustus 2026 terhadap kedua puluh berkas dex build debug. Yang sama sekali tidak ada: crashlytics, FirebaseAnalytics, com.google.android.gms.measurement, firebase/perf, remoteconfig, inappmessaging.

Satu-satunya yang namanya mengandung kata analytics adalah firebase-measurement-connector, yang isinya empat antarmuka dan satu kelas kosong. Itu adalah lubang colokan tempat Analytics akan dipasang seandainya Analytics ada, dan di sini tidak ada apa pun yang mengisinya.

Kalau Anda menjalankan pemeriksaan itu, pastikan dulu alat-alatnya benar-benar berjalan. Percobaan pertama pemeriksaan ini melaporkan hasil bersih justru karena salah satu alatnya tidak terpasang dan seluruh rangkaiannya gagal tanpa suara. Pemeriksaan yang lulus tanpa pernah berjalan terlihat persis sama dengan pemeriksaan yang lulus.

Yang tidak dibuktikan oleh bagian ini

  • Anda hanya bisa memeriksa build yang ada di tangan Anda. Latchat belum dirilis, jadi hari ini belum ada build yang bisa Anda unduh dan periksa sendiri.

Yang belum ada

Ditulis di sini supaya Anda tidak perlu menemukannya sendiri.

  • Kode sumbernya tidak publik.
  • Belum ada audit keamanan dari pihak ketiga.
  • Model ancamannya tidak dipublikasikan. Dokumennya ada dan ditulis pada 7 September 2026, tetapi seperti kode sumbernya, Anda tidak bisa memeriksanya. Isinya menyebut hal-hal yang tidak bisa ditutup dengan kode, dan itu tiga: kode sumbernya tidak publik, belum ada yang menyerangnya dari luar, dan server perantara tetap melihat metadata.
  • Server perantara tetap melihat metadata. Bukan isi pesan, tetapi pola hubungan dan aktivitas. Rinciannya ada di kebijakan privasi.

Technical

How Latchat works

What the app actually does with your messages, what you can check for yourself, and what none of it establishes.

This page is a description, not a proof. Latchat's source is not public, and nobody outside this project has audited it.

What a page like this can do is be specific enough to be wrong in public. So every section below ends with what it does not establish, and those parts are written in earnest.

1. Encryption

The claim: message content is encrypted end to end, and our server holds no key that opens it.

How it works

Every message is sealed with XChaCha20-Poly1305 before it leaves your phone, under a key made for that one message. The message id and the routing fields are authenticated alongside it, so a relay that alters them breaks the seal and the message is refused.

Those keys come from a group key that every member derives for themselves and no server holds. Each sender has their own chain from it and each message its own key, drawn from that sender's sequence number. The nonce is derived from the same number rather than picked at random, so a repeated nonce would mean a repeated sequence number, and that is something another phone can see and refuse.

Identity is Ed25519, key agreement is X25519, and BLAKE2b does key derivation and the group's own MAC. An invitation sent by link is sealed under numbers stretched with Argon2id at 256 MiB of memory and three passes, which is why a phone takes several seconds over it. All of it comes from libsodium, pinned to one version with a checksum in the build. Nothing here is hand-rolled.

Groups do not use a double ratchet, deliberately. Mesh messages arrive out of order and hours late, and a ratchet would spend its life holding keys for messages still sitting on a phone three valleys away. One key per epoch opens any message from that epoch whenever it turns up. The cost is stated rather than hidden: no forward secrecy inside an epoch. What actually ends somebody's access is removing them, which re-keys the group.

Every message is also signed with its sender's own private key, not only sealed. The group seal proves a message came from inside the group; the signature is what proves which member sent it. Without one, any member could put somebody else's name on a message, because every member derives the same group key.

What you can check yourself

Point a network monitor at a phone running Latchat. It talks to exactly two hosts: Google's push service, and relay.latch.chat. What crosses to the relay is a sealed envelope.

Read the privacy policy. It prints as a table what the relay genuinely does see, and it is not nothing: the pattern of who talks to whom, when, and how much.

What this does not establish

  • Sealed bytes at the relay prove the relay receives ciphertext. They do not prove the app did not also keep a copy of the key somewhere. Only the source answers that, and the source is not public.
  • There has been no third-party audit. Nobody outside this project has read the code.
  • A signature proves who wrote a message. It does not prove the message is true. A member of your group can still lie in their own name, and no messaging app can fix that.
  • No forward secrecy inside an epoch: anybody who got an epoch key off a phone could open the messages from that epoch which are still stored on it.

2. The paths: internet first, Bluetooth when there is none

The claim: the internet is the ordinary path, Bluetooth is the alternative, and neither one is promised.

How it works

Where there is a connection, a message is left with a small relay belonging to your group. It holds sealed envelopes for at most 24 hours and wakes a sleeping phone with an empty push, which carries nothing at all beyond "something is here, wake up".

Where there is not, phones in the group connect to each other directly over Bluetooth and pass on whatever they are carrying. A message stops travelling when it has reached everybody, or when its 24 hours run out.

Both paths are used at once rather than one after the other. And neither is promised: the app never shows a delivered state it cannot prove.

What you can check yourself

This is the part you really can establish for yourself, and it takes five minutes and two phones that are in the same group.

One. Put both phones in aeroplane mode, then switch Bluetooth back on and nothing else. No internet, no mobile signal. Send a message. It arrives.

Two. Now turn Bluetooth off on both and turn wifi on. Send a message. It arrives too.

On distance, this is what was measured, one outdoor session on 13 August 2026 with two phones: about 30 m for a link that still carries a message, and 51 to 55 m before a phone stops being detected at all. Those two numbers are far apart, and the front page quotes the smaller one, because being detected is not the same as being able to exchange a message.

What this does not establish

  • The distances come from one session, one pair of phones, outdoors, screens on. Indoors has never been measured at all.
  • Neither path guarantees delivery. A push to a sleeping Android phone was measured arriving a median of about 4,392 seconds late at ordinary priority. That is over an hour, and it is a measurement rather than an estimate.
  • If everybody is out of Bluetooth range and there is no connection, a message waits. It is not lost, but it has not arrived, and after 24 hours it stops being carried.

3. What is not inside the app

The claim: no analytics, no crash reporter, no ad SDK, no tracker. One exception, and only one: Firebase Cloud Messaging, used to wake a sleeping phone, because on Android there is no substitute for it.

What you can check yourself

An APK is a zip archive. Open it and read the class names inside its .dex files. If an analytics SDK is in there, its name is in there.

That scan was run on 25 August 2026 across all twenty dex files of the debug build. Absent entirely: crashlytics, FirebaseAnalytics, com.google.android.gms.measurement, firebase/perf, remoteconfig, inappmessaging.

The only thing with "analytics" in its name is firebase-measurement-connector, which contributes four interfaces and one empty class. It is the socket Analytics would plug into if Analytics were present, and nothing here fills it.

If you run that scan, check that your tools actually ran. The first attempt at it reported a clean result precisely because one of the tools was not installed and the whole pipeline failed silently. A check that passes while never running looks exactly like a check that passes.

What this does not establish

  • You can only inspect a build you have. Latchat is not released, so today there is nothing for you to download and scan.

What is missing

Written here so that you do not have to discover it.

  • The source is not public.
  • There has been no third-party security audit.
  • The threat model is not published. It exists, written on 7 September 2026, but like the source you cannot inspect it. What it names are the things no code change can close, and there are three: the source is not public, nobody outside this project has attacked it, and the relay still sees metadata.
  • The relay still sees metadata. Not content, but a pattern of contact and activity. The detail is in the privacy policy.