AES-256
For everyday messages
AES-256 is a widely used encryption standard. QR Crypt uses it by default. Each message fits in a single QR code, and you exchange the key in person.
What this is
Encrypt offline. Transfer by QR code.
QR Crypt is a small app that runs on a device you keep permanently offline. Enter a message, and the app encrypts it and displays the ciphertext as a QR code. Your everyday online device scans the code, converts it to text, and sends it through any messaging app. The recipient follows the same process in reverse. In the intended workflow, plaintext is handled only on the sender’s and recipient’s offline devices; the online devices relay ciphertext.
- No accounts. No QR Crypt relay server. The app does not send plaintext or secret key material over a network.
- Two devices per person: one offline and one online.
- Open source under the Apache License 2.0; not independently audited.
Encryption
Convenience or long‑term confidentiality
Choose based on how long the message needs to remain confidential.
ML-KEM-1024
For messages that must stay private for decades
A sufficiently capable quantum computer could break many of the public-key mechanisms widely used for key exchange today. Because state intelligence agencies are likely to remain at the forefront of practical cryptanalysis, QR Crypt uses ML-KEM-1024 to prepare for future quantum attacks, including attacks by state-level adversaries. It is intended for messages that require long-term confidentiality against such highly capable attackers. The trade-off is greater processing and data overhead, so each message is split across multiple QR codes.
Getting it
Two ways to install it
Route A
Verify the signed ZIP
This is the default route and the only one intended for high-assurance use. On a trusted computer, download the signed release and verify both its signature and checksum using verification values obtained through an independent channel. Independently rebuild the same commit, then compare the set of payload files and their hashes with the release. Cosign attests which workflow published the artifact; it does not prove that the binary corresponds to the source.
Transfer the archive to the offline device, extract it, and serve the folder with a static web server bound only to 127.0.0.1. Follow the bundled INSTALL.txt: use an audited static server obtained through an independent, trusted process and installed on the offline device in advance. Apply the bundled headers and redirect rules. Merely installing a server through a process labeled “trusted” does not provide equivalent assurance.
Do not open index.html directly from a file:// URL. In that context, browser storage isolation does not hold, so another local HTML file may be able to read your keys. The transfer medium—such as a USB drive or SD card—must also be trusted, because anyone who can modify it can modify the app. The repository contains the complete procedure.
Get the latest release github.com/transparent-pegasus/qr-crypt Read the full install procedure docs/develop/install-route-a/README.md
Route B
Install it from the live origin
On the device you will keep offline, open this site, choose Install or Add to Home Screen, and then disconnect the device from every network. This route offers no integrity check that the user can perform. An attacker who controls the origin server, TLS endpoint, or CDN could deliver a modified bundle to a single target device without detection, and the service worker could keep that modified bundle installed. The app also remains associated with the live origin.
If the device reconnects, it sends a reachability probe to that origin. Wiping begins only after the sentinel responds, so the probe necessarily leaves the device before the wipe starts. Route A uses only 127.0.0.1; after the dedicated server is stopped and its reserved port is not reused, nothing is listening there. Never treat airplane mode alone as proof that a device is trustworthy.
Using it
How a message travels
Throughout all six steps, plaintext remains on the offline devices. Only ciphertext and the framing data needed to carry it cross the boundary. The key-exchange process depends on the method. A symmetric key is scanned in one direction only. With post-quantum identities, each person must scan the other person’s public key when signatures are used or messages travel in both directions. The steps below show the post-quantum identity workflow.
-
Each person creates their own key
Create dialog
-
Each person loads the other's key
Import dialog
Exchange keys face to face and compare the on-screen fingerprints. The app cannot determine whether a key actually belongs to the person you expect.
-
The sender encrypts the message
Encrypt page
Encrypt the message with the recipient’s key. If you choose a signed suite, your key signs the message so the recipient can verify who sent it.
-
The online device scans the QR code from the offline screen.
Scan the QR code and send the text
Online mode
-
The recipient turns the text back into a QR code
Online mode
-
The offline device scans the QR code from the online screen.
The recipient decrypts and reads it
Decrypt page
The plaintext never leaves this device.