Velrix Open Source E2E Encrypted Messenger on Raspberry Pi Kiosk Hardware

We built a fully air-gapped style encrypted messenger that runs on a Raspberry Pi

with a 3.5" touchscreen. No phone. No laptop. No desktop. A dedicated physical

device purpose-built for secure comms. Sharing it here because this community

understands why that matters.

────────────────────────────────────────────────────────────────

WHAT IT IS

────────────────────────────────────────────────────────────────

Velrix is a self-hosted, end-to-end encrypted messaging system consisting of two

parts:

1. A Rust API server running inside Docker on your own VPS, exposed only as a

Tor hidden service (.onion). The server never touches plaintext. It stores

only ciphertext blobs and has no knowledge of message content.

2. A pygame kiosk client that runs fullscreen on a Raspberry Pi Zero 2W (or

any Pi) with a SunFounder 3.5" IPS TFT touchscreen. The device boots

directly into the app no desktop, no browser, no shell visible to the user.

────────────────────────────────────────────────────────────────

SECURITY MODEL

────────────────────────────────────────────────────────────────

• E2E encryption X25519 ECDH key exchange + XSalsa20-Poly1305 (NaCl Box).

Messages are encrypted on-device before transmission. The server cannot read

them. Ever.

• Keys never leave the device Ed25519 signing key and X25519 encryption key

are generated locally on first setup and stored in ~/.messenger/ (mode 700).

They are encrypted at rest using Argon2id key derivation from your PIN.

• All traffic through Tor, the app blocks at boot until the Tor SOCKS5 port

is ready. There is no clearnet fallback. No DNS leak. No IP leak. The server

address is a .onion it cannot be reached any other way.

• PIN-protected, 6-digit PIN required on every unlock. 10 wrong attempts

triggers a 30-second lockout. Keys are wiped from memory on lock.

• Emergency wipe, hold the ⚠ button for 3 seconds. Wipes keys, contacts,

session tokens, and config from the device instantly. Nothing recoverable.

• No phone number. No email. No account recovery. No cloud backup.

Enroll with a one-time token from the server. That's it.

• Auto-lock after 5 minutes of inactivity.

• Messages have expiry timers, visible countdown on each thread. Expired

messages are purged automatically. Server also enforces expiry server-side.

────────────────────────────────────────────────────────────────

THE HARDWARE

────────────────────────────────────────────────────────────────

Raspberry Pi Zero 2W ~£15 / $18

SunFounder 3.5" IPS TFT ~£20 / $25

microSD 8GB+ ~£5 / $6

5V micro-USB power supply ~£5 / $6

Total per unit: under £50 / $55

The screen runs at 480×320 over SPI, driven by fbtft kernel overlay. X11 on

/dev/fb1 via xserver-xorg-video-fbdev. SDL2 renders under X11. Touch input via

ADS7846 driver with a 180° coordinate transformation matrix to match display

rotation. The whole thing boots in ~30 seconds from cold power-on to PIN prompt.

────────────────────────────────────────────────────────────────

THE SCREENS

────────────────────────────────────────────────────────────────

[ATTACH: screen_1_splash.png]

Boot splash, shows while waiting for Tor to build a circuit.

WiFi button bottom-right if you need to connect before Tor can route.

[ATTACH: screen_2_lock.png]

Lock screen, PIN entry every boot and after 5 min idle.

6-dot indicator. Wrong attempts trigger lockout.

[ATTACH: screen_3_inbox.png]

Inbox, one row per conversation, newest first.

Shows sender, preview, message expiry countdown, unread count.

Green dot = Tor active. Shows last sync time.

[ATTACH: screen_4_compose.png]

Compose, on-screen keyboard. Type recipient username, type message, send.

Message is encrypted on-device before it leaves over Tor.

────────────────────────────────────────────────────────────────

HOW MESSAGES WORK

────────────────────────────────────────────────────────────────

1. Device A looks up Device B's X25519 public key from the server.

2. ECDH shared secret is derived locally.

3. Message is encrypted with NaCl Box (XSalsa20-Poly1305) using the shared secret.

4. Ciphertext is POSTed to the server over Tor.

5. Server stores the blob, it has no key and cannot decrypt it.

6. Device B polls the server (every 20s by default), fetches the blob, decrypts

locally with its private key.

7. Plaintext never touches the server or the network in any form.

The server is essentially a dead-drop. It holds encrypted blobs until they are

collected or expire. That's the entire threat model.

────────────────────────────────────────────────────────────────

INSTALL

────────────────────────────────────────────────────────────────

Server (your VPS, runs Docker):

git clone / copy server files

docker compose up -d --build

Get your .onion address from the Tor container

Generate an enrollment token via SQL or admin panel

Client (Pi, one command):

./install.sh

# reboots to install TFT driver

INSTALL_SCREEN_DRIVER=0 ./install.sh

# sudo reboot, device is live

The installer handles everything: driver, kernel overlay patch for touch on

kernel 6.x, NetworkManager, Tor, Python venv, Argon2, PyNaCl, auto-login on

tty1, kiosk launcher, Xorg config, passwordless nmcli for in-app WiFi.

────────────────────────────────────────────────────────────────

OPSEC NOTES

────────────────────────────────────────────────────────────────

• Buy the hardware with cash. These components are widely sold at electronics

markets and hobby shops, no account or delivery address needed.

• Flash the SD card offline. Raspberry Pi Imager works without an account.

• Run your own server. Don't trust a shared instance. A VPS paid with Monero

and accessed only over Tor keeps the server operator out of the picture.

• The Pi has no browser, no shell access from the screen, and no obvious

function to anyone who picks it up, it shows a PIN screen.

• If compromised physically: 3-second hold on ⚠ wipes the device.

There is no cloud backup to pull from. The keys are gone.

• Two units minimum. One per person communicating. Each registers with its own

username and keypair.

────────────────────────────────────────────────────────────────

LIMITATIONS / HONEST TRADE-OFFS

────────────────────────────────────────────────────────────────

• Tor latency, messages take 1–5 seconds to send over .onion. Not instant.

Polling is every 20 seconds by default so incoming messages are not instant

either. This is a deliberate trade-off for anonymity over speed.

• No group messaging - 1:1 only right now.

• No attachments - text only.

• Server metadata - the server knows when a device checked in and that a

message exists between two device IDs. It does not know content, usernames

in plaintext, or real identities. Still run your own server.

• Physical security - if someone gets the device and has time to brute-force

the PIN before you can wipe it, the keys could be extracted. Argon2id slows

this significantly but it's not magic. Use a non-trivial PIN.

────────────────────────────────────────────────────────────────

Not looking to sell anything. Not a service. Just hardware + software you build

yourself and control entirely. The install script and all client/server code is

available ask here

Questions welcome.

https://dump.li/i/dc0460.png

https://dump.li/i/43e8c7.png

https://dump.li/i/4563fb.png

https://dump.li/i/182d78.png

This is pretty neat

Thank you

Interesting design.

The idea of running on top of a Raspberry device is really nice. Way better than relying on a mobile app, coming with endless hardware and OS vulnerabilities. There's something cool too with the blueprint being secured yet simple. Curious to check your source repository when it will be available :)

At the meantime, I'm a bit hesitant as for the actual advantages of running such a device. Using dedicated hardware rocks, but what's the actual gain compared to just run another Debian-based VM or Tails plug? It is harder to conceal and doesn't enable the same mobility as a smartphone anyway. Also, while you didn't mention it, you'll have to deal with the underlying OS all the same. ISP too. Same thing goes with the VPS side. If you don't bring your own network (which is fine by me), why not just run a private XMPP server? It has been around for a while, had plenty of feedback, is widely supported, and I'm pretty sure you can run it into docker. To my knowledge, it supports proper E2E and PFS. So... I guess my point is, what's the angle here?

Also for an additional question, how are the servers broadcasted? Do you need to select a specific instance to discuss with a user being a member of it?

The angle isn’t “better encryption” or “new protocol” those problems are already solved well. The angle is attack surface reduction through physical and software minimalism.

A Debian VM, Tails, or even a hardened laptop still carries a huge amount of complexity:

general-purpose OS

background services

browser stack

package managers

user multitasking

large kernel + drivers + subsystems

Velrix deliberately throws all of that away.

You’re interacting with:

one fullscreen process

no shell access

no browser

no installable apps

no userland beyond what’s required to boot, render UI, and pass encrypted blobs over Tor

That changes the security model quite a bit.

Why dedicated hardware instead of a VM / Tails?

A VM or Tails session is still:

ephemeral but user-driven

running on untrusted host hardware

exposed to host OS compromise, keylogging, screen capture

easy to accidentally misuse (open a browser tab, copy/paste, etc.)

Velrix is:

single-purpose

non-multitasking

no data exfil paths by design (no clipboard, no apps, no browser)

predictable state machine (boot → unlock → message → lock)

It’s closer to a hardware token for messaging than a computer.

Also important: human error reduction.

Most real-world failures aren’t crypto breaks, they’re operational mistakes.

On concealability / mobility

You’re right, it’s not trying to replace a phone.

This sits in a different category:

stashable device

used intentionally, not constantly

closer to a secure terminal than a daily communicator

Think:

pre-arranged comms

specific contexts where you don’t want convergence with your personal device

If your threat model values convenience, this is worse than a phone.

If your threat model values separation, it’s better.

“You still trust the OS / ISP / VPS”

Yes, and that’s acknowledged.

The goal isn’t to eliminate trust completely (that’s unrealistic), but to:

minimize what each layer can see

So:

ISP sees Tor, not destination

server sees ciphertext blobs, not content

OS runs minimal services, no general-purpose interaction surface

You’re reducing correlation + exposure, not claiming invisibility.

Why not XMPP (OMEMO, etc.)?

XMPP is solid, but it brings a different philosophy:

identity layer (JIDs, federation)

richer protocol surface

more metadata

larger codebase

multi-client ecosystem (which is both strength and weakness)

Velrix strips this down to:

no federation

no discovery

no presence

no multi-device sync

no extensibility

Just:

“here is a public key, here are encrypted blobs”

Also, fewer moving parts = easier to audit end-to-end.

It’s not trying to compete with XMPP, it’s intentionally less capable.

Server discovery / how users connect

There’s no public network or federation.

Each server is a Tor hidden service (.onion)

You only connect if you have that address

Enrollment is via a one-time token generated server-side

So effectively:

server = closed environment

users must be invited

no global directory, no broadcast, no discovery

If two people are on different servers, they can’t talk unless:

they share the same server

or you manually bridge (not implemented)

TL;DR

The trade-off is deliberate:

You lose:

convenience

features

mobility

ecosystem compatibility

You gain:

drastically reduced attack surface

strong separation from everyday devices

simpler, more auditable system

fewer ways for users to make mistakes

It’s not “better than XMPP” or “better than Tails” universally

it’s a different point in the design space.

Thanks for the detailed answer. Focusing on the conclusion and especially the gains - as we already agree on the loss.

drastically reduced attack surface

I find this debatable. I guess Raspberry Pi has less features than your average laptop, but I don't think it makes for such a big difference once the device is being seized and submitted to forensics. What's blocking an attacker to root the device by setting a screen, keyboard, etc.? What about low-level UNIX vulnerabilities - and where's the gain compared to more common options?

strong separation from everyday devices

Agreed.

simpler, more auditable system

Agreed to some extend. Any open-source library simple enough is auditable. Your design sounds pretty straightforward; but it also relies on UNIX machines both on client and server side, runs under usual network constraints, etc. Still curious to check a source :)

fewer ways for users to make mistakes

I guess so, except for the network part.

You only connect if you have that address

Something of a detail but do you expect the user to copy the complete onion domain from another device to yours through a touch screen?

Thanks for the thoughtful response, this is exactly the kind of scrutiny I’m looking for.

On the attack surface point, I agree that once a device is physically seized and subjected to proper forensic analysis, a Raspberry Pi doesn’t magically become “secure.” If an attacker has time, tools, and physical access (keyboard, display, etc.), they can absolutely attempt to root or extract data, same as with any UNIX-based system.

The gain I’m pointing to is more practical than absolute:

The system is designed to be single-purpose, with minimal services, no general user environment, and no day-to-day software exposure (browsers, email clients, etc.), which reduces remote and accidental attack vectors significantly.

Compared to a typical laptop or phone, there are simply fewer pathways for compromise before seizure.

That said, you’re right that this doesn’t fundamentally stop a determined forensic attacker, it just narrows the window of exposure.

On the forensics angle, one important distinction in this design is the use of removable microSD storage:

The entire system (OS + application + keys) lives on a microSD card

This makes it much easier and faster to physically remove, destroy, or conceal compared to a laptop with soldered or internally mounted storage

The goal here isn’t to resist deep forensic analysis indefinitely, but to reduce recoverability under real-world time constraints

So the security model leans more toward:

minimizing exposure + enabling rapid data denial, rather than assuming the device will survive full forensic examination.

On the onion address point, you're right to call that out, we’re not expecting users to manually copy long domains across devices. The current direction is:

Users can create and manage their own isolated networks

Discovery and connection will be handled in a more controlled way (still evolving), rather than manual entry of onion addresses

And agreed on your other points, especially around auditability and network-related risks. Those are areas where the design still needs to prove itself in practice.

Appreciate the pushback, it’s helping tighten the model.

Makes sense. I guess you've got something with both the item and the stupid-proof design. Maybe it can get traction. There's a few pitfalls I'd be curious to look at but there's no hurry either. I'll check your release when it's out :)

DM Sent