Home Reviews About
Twenty of Time

How to encrypt messages without relying on an app

Encryption is often presented as a feature you switch on inside a messaging service. That is convenient, but it also places trust in the service provider, its software supply chain, its account-recovery process and the device running the program. If the goal is to communicate privately without depending on a particular app, the first step is to separate encryption from the interface used to send a message.

There is an important limit: digital encryption requires some software to perform the calculations. A phone, computer or browser is already running software, even when no dedicated messaging app is installed. If “without an app” means no third-party messenger, command-line tools and offline utilities can help. If it means no electronic software at all, the realistic option is a paper-based one-time pad.

This distinction matters in Australia, where ordinary communications pass through mobile networks, cloud services and advertising systems. A message can be encrypted in transit yet still reveal who contacted whom, when, from which location and through which account. The privacy discussion on Twenty of Time is useful precisely because it treats surveillance as a social and political issue, rather than a setting hidden in a menu.

Decide what needs protection

Encryption protects the content of a message. It does not automatically hide the fact that two people communicated, the time of the exchange, the size of an attachment or the internet connection used. This surrounding information is called metadata, and it can be revealing even when the words remain unreadable.

Consider a person in Sydney messaging a solicitor, a journalist or a health clinic. The message body may be encrypted, while the phone provider still records network events. Australian telecommunications companies have obligations under the Telecommunications (Interception and Access) Act to retain certain metadata for two years. That does not mean every private conversation is routinely read, but it does mean that content secrecy and communication secrecy are separate goals.

A useful threat model identifies the person or organisation you are trying to keep out. A curious flatmate needs protection from screen previews and unlocked devices. An advertiser needs protection from profiling and cross-site tracking. A determined attacker may target passwords, backups, endpoints or the person holding the decryption key. These threats call for different measures.

The Australian Privacy Act and its evolving reforms can create obligations for organisations, yet legal compliance is not a substitute for technical privacy. The discussion of advertiser shadow profiles shows why data can remain useful for profiling even when a company avoids directly reading message content.

Use a paper one-time pad for true app-free secrecy

A genuine one-time pad is the clearest way to encrypt a short message without an electronic tool. Two people first create identical sheets of random key material. The key must be at least as long as the message, used once only and kept secret. After both people have a copy, the sheets are destroyed or stored separately from the messages they protect.

To encrypt text, remove punctuation, convert letters to numbers from 0 to 25 and add each plaintext value to the matching key value. Reduce every result modulo 26. The recipient subtracts the same key values to recover the original letters. Spaces can be represented by a separate convention, or the message can be written in fixed groups such as five letters.

The quality of the key is decisive. A memorable phrase, a page from a novel or a predictable sequence is not random enough. Dice can generate random numbers on paper, provided the process is careful and the results are recorded accurately. The two copies must be made before communication begins, and neither copy should be photographed or stored in a cloud drive.

One-time pads are impractical for casual conversation. They require secure key distribution, careful counting and a way to authenticate the sender. A thief who obtains an unused pad can read future messages, while reusing a pad can allow an observer to compare ciphertexts and recover patterns. This method is best reserved for rare, short and unusually sensitive communications.

Replace the messenger with offline encryption tools

For regular digital communication, the practical alternative is to encrypt a text file locally, then send the resulting ciphertext through email, a file transfer service or even an ordinary message. The channel carries unreadable data; the encryption happens before the data reaches it. This avoids reliance on a particular social or chat platform, although it still relies on a trustworthy encryption program.

Command-line tools such as GnuPG or age can run locally on macOS, Linux and Windows environments. They are not magic invisibility devices, and they are still software, but they reduce dependence on a company’s account system and interface. A sender can create a file containing the message, encrypt it to the recipient’s public key, and transfer the encrypted file. The recipient uses a private key stored on their own device.

Public-key encryption solves the key-sharing problem more elegantly than a shared password. The public key can be distributed openly, while the private key remains secret. The difficult part is confirming that the public key really belongs to the intended person. Verify its fingerprint through a separate channel, such as an in-person meeting or a phone number already known to be genuine. Never accept a changed key without checking why it changed.

Symmetric encryption is simpler for a small group that already shares a strong secret. A locally encrypted archive can contain the message, but the password should travel through a separate route. Sending both the ciphertext and its password in the same email provides little protection. Built-in disk encryption is helpful for a stolen laptop, yet it does not protect a message once the device is unlocked or compromised.

Protect keys, devices and the conversation around them

The endpoint is usually more important than the encryption algorithm. If malware, a malicious browser extension or an unauthorised person can read a message before encryption or after decryption, perfect mathematics cannot help. Use a separate user account where practical, install security updates, enable full-disk encryption and lock the screen when leaving a device unattended.

Key backups require particular care. Losing a private key can make old messages permanently inaccessible, while exposing it can reveal every message protected by that key. An encrypted offline backup stored in a secure place is safer than an unprotected USB stick. Keep a record of which key belongs to which person, and revoke or replace keys when a device is sold, lost or suspected of compromise.

Avoid putting plaintext in clipboard histories, notification previews, cloud backups and automatic photo uploads. A message typed into a normal notes app may be copied into synchronised storage before it is encrypted. On an Android phone or iPhone, review lock-screen notifications and keyboard permissions. On a shared computer in Melbourne or Brisbane, assume that browser profiles and downloads may remain available after a conversation ends.

Authentication deserves equal attention. Encryption can keep an attacker from reading a message while failing to prove who sent it. A signed message, a verified key fingerprint or a prearranged code phrase can help detect impersonation. This matters during account recovery, SIM replacement and urgent requests for money, documents or passwords.

Understand the channel and the legal setting

Encrypted content can still draw attention if its pattern is unusual. Large ciphertext attachments sent at regular intervals may be conspicuous, and a service may retain account data even though it cannot read the payload. A privacy tool should therefore be judged by its handling of logs, contacts, backups and identifiers, not just by a claim of end-to-end encryption.

A completely app-free method also has social costs. The other person must know how to handle a pad or decrypt a file, and mistakes become more likely when the process is unfamiliar. A secure system that nobody can use consistently may provide less protection than a well-designed encrypted messenger used correctly. The question is not whether software exists, but how much unnecessary trust it demands.

Australian users should also understand the legal context without treating it as a reason to abandon encryption. The Assistance and Access Act 2018 created powers for agencies to seek technical assistance in investigations, while placing limits around systemic weaknesses. Organisations may face disclosure or data-retention duties, and a provider’s promise cannot override every lawful request. Personal encryption remains a sensible way to reduce routine exposure to theft, commercial tracking and accidental disclosure.

There is a wider social choice involved. Building a privacy-first social network is difficult because privacy depends on defaults, business models and network effects, not just cryptography. The same principle applies to private messages: secure communication depends on the surrounding system, including who controls the service and where copies are stored.

Method Needs a dedicated messenger Key distribution Protects message content Main weakness
Paper one-time pad No Secure physical exchange Very strong when used correctly Slow, fragile and difficult to authenticate
Local public-key encryption No Verify a public-key fingerprint Strong against interception Private-key loss or endpoint compromise
Local shared-password archive No Share a strong secret separately Strong if the password stays secret Password reuse and weak sharing practices
Ordinary SMS or email No Managed by the provider Usually little or no end-to-end protection Provider access, metadata and backups
Encrypted messenger Yes Usually handled by the service Strong when implemented correctly Trust in the app, device and provider

The most independent approach is therefore a matter of degrees. For a rare, short secret, a properly generated paper one-time pad avoids apps entirely. For routine digital files, local public-key encryption avoids dependence on a messaging company while retaining practical usability. In every case, verify the recipient, keep private keys offline where possible, minimise metadata and remember that a locked message is only as secure as the device that opens it.

A practical rule is simple: encrypt locally, verify keys through a separate channel, send only the ciphertext, and remove avoidable plaintext copies from notifications, backups and shared devices.