Your message is encrypted. The envelope is not.

Encryption hides what you wrote. It does not hide when you wrote it, how often, how large it was, or who you sent it to. This is a plain guide to everything encryption leaves in the open, and to the one tool that decides how much of it leaks.

Picture a letter you have closed inside an envelope. Anyone who intercepts it in the post cannot read a word of what is inside, and that is a real and valuable protection. It is also tempting to treat it as the whole of privacy, and it is not. The closed envelope still has a size and a weight. It still carries a postmark with a date and a place. It still names a sender and a recipient, and it still sits in a sorting office alongside every other letter you have sent this month. None of that is the letter itself. All of it describes you. Someone who never opens a single envelope, but who watches the shape and the timing of the ones you send, can learn a great deal about how you live.

Digital encryption is the lock on that envelope, and it inherits the same limitation. Understanding exactly where the lock stops is the difference between a product that sounds private and one that is. So it is worth being precise, from the beginning, about what encryption promises and what it quietly leaves in the open.

What encryption does, and what it does not

Encryption gives you confidentiality. It turns the contents of a message into something unreadable to everyone except the holder of the key. That is the part almost everyone already understands, and it is genuinely the hard, important core of the whole field. Two things it does not do on its own are worth stating just as plainly, because the gap between the promise and the assumption is exactly where privacy tends to leak.

The first is that encryption conceals the contents of a message but not its existence, its size, or its timing. A scrambled message is still a message of a certain length, sent at a certain moment, between two certain parties. The second is more surprising to a newcomer: plain encryption does not, by itself, prove that a message arrived unaltered. Making data unreadable and detecting whether that data has been tampered with are two separate jobs. For many years they were treated as two separate steps, and when the second step was done carelessly, or skipped, the results were often broken in ways that had nothing to do with anyone reading the contents. Hold on to that distinction between secret and unaltered. It is the hinge the rest of this piece turns on.

The part that survives has a name

The information left in the open when the contents are encrypted is called metadata: data about your data. Not what you said, but everything around it. In a private notes application that means the number of items you keep, the moment each one was last edited, the size of each one down to the byte, the kind of thing each one is, and the identifier that ties the whole collection back to your account. Taken one field at a time, each looks harmless. Taken together, they are a detailed outline of a life. A forty-minute item created at nine in the morning, followed three minutes later by two short ones, followed by a long quiet gap, is a meeting and its aftermath, reconstructed without a single word of it being read.

The demonstration below makes the point directly. Encrypt the contents and watch what stays legible.

The body becomes noise, and it should. The row beneath it does not move. That row is the outline, and a serious privacy product treats it as something to protect in its own right, rather than as harmless exhaust. Which brings us to the tool that makes protecting it possible.

From scrambling to a lock that also proves authenticity

The mechanism modern systems reach for is authenticated encryption, usually written as AEAD, a step beyond the plain encryption most people picture. The name rewards being unpacked slowly, because every part of it does real work. The encryption is the confidentiality you already have: the contents become unreadable. The authenticated is that second job from earlier, now done properly and in the same operation. Alongside the scrambled contents, the process produces a short cryptographic value called a tag: a tamper-evident mark that only someone holding the key could have generated. When the message is opened, the recipient recomputes the tag from what they received and checks that it matches the one attached. If a single bit of the ciphertext has changed, by accident or by design, the two tags disagree and the message is rejected rather than trusted.

Confidentiality keeps the contents secret. Authenticity keeps them honest. AEAD delivers both in a single step, which is why it is the modern default rather than an optional extra.

The quiet idea that most explanations skip

There is a third letter in that acronym, and it is the one that matters most for metadata. The AD in AEAD stands for associated data, and it is the feature that lets the tag reach beyond the encrypted contents to cover information that has to stay readable. Some fields around a message cannot be hidden, because the system needs to read them without the key in hand: which item this is, what version of it this is, what kind of thing it holds. Associated data lets you feed those plaintext fields into the same authenticated operation as the contents. They are not encrypted, and they remain perfectly legible. But they are now bound to the ciphertext. Alter the visible version number, or the type, or the identifier, and the tag stops matching, precisely as if you had altered the secret contents. The label stays readable and, at the same time, becomes forgery-evident. This is the single most useful idea in the subject, and it is the one most often left out.

It is easier to see once you watch it happen. Your notes sync through a cloud, and the promise of end-to-end encryption is that you never have to trust that cloud with the words inside. But a dishonest cloud can still play a trick without reading a thing: instead of returning your newest note, it hands your device an older copy it kept from before. Run the attack below, first with the version bound into the lock and then without, and watch what your device does with what it is handed.

What goes wrong when the label sits outside the lock

The failure this prevents is quiet, because it never requires reading the contents. Suppose the version number of a note travels next to the ciphertext but is not bound into it. An attacker who controls the storage or the network still cannot read the note. What they can do is hand you back an older, genuinely valid locked copy while claiming it is the newest one. The lock on that old copy is perfectly intact, so your device accepts it without complaint, and the edit you made yesterday quietly vanishes. The same gap lets an attacker relabel one kind of item as another, reorder a sequence of them, or, in a close cousin of the problem, push a system back onto an older and weaker format by tampering with a version marker that nobody thought to authenticate.

A long line of real-world encryption failures over the past two decades share this exact shape. The payload was encrypted competently. The fields around it, the headers and version numbers and type markers, were left unauthenticated, and those fields alone were enough to cause real harm. None of it was a failure of the cipher. All of it was a failure to decide what the lock should cover. Binding the surrounding fields into the lock is what closes the gap, and it costs almost nothing to do.

One more thing, for the reader who already knows this

There is a discipline that belongs beside the two above, and it is where careful systems have still come undone, so it earns a mention rather than a footnote. Every AEAD operation consumes a value, usually called a nonce, that must never repeat for a given key. Reuse one with the same key and you do not merely weaken the lock; for several common constructions you can unravel confidentiality and authenticity together. It is an easy mistake to make at scale, under retries and restarts and a user with several devices, and it is worth designing against on purpose rather than assuming away. The point of raising it here is not to drift into the weeds. It is the reminder that using AEAD is where the work begins, not where it ends, and that the safety lives in the details.

Two disciplines, not one

Everything above reduces to two habits, and a private system needs both of them. The first is to authenticate the metadata you have to keep: bind the version, the type, and the identity into the lock, so that a stale or altered copy fails to open rather than opening to the wrong thing. The second, and the one that is easier to forget, is to keep less metadata in the first place. Authentication protects a field from being changed. It does nothing to hide that the field exists at all. The safest field is the one you never wrote to disk, and the safest thing to hand a server is the least it needs to do its job. A system that dutifully authenticates a mountain of metadata is more honest than one that leaves it exposed, but it is still standing next to a mountain.

We hold our own product to this

We recently ran a full audit of Privt against exactly these questions, and we tightened the places where our own metadata could say more than it should. We would rather find that ourselves and tell you plainly than have someone find it for us and tell you first. It is a slower way to build a company, and we think it is the only way worth building one. The measure of a private tool is not only whether it can read your words. It is how little it needs to know in order to work, and how much of what it does know it has bothered to encrypt.

For readers who want the exact mechanics, our whitepaper sets out how Privt encrypts every note on your Mac, binds its metadata into the lock, and what it deliberately declines to keep. For everyone else, the short version is the one you started with: your message is encrypted, and we work to make sure the envelope gives away as little as possible.