Privacy foundations

Ciphertext, plaintext, and metadata.

Plaintext is the readable input to encryption; ciphertext is the transformed output intended to be unreadable without the correct key. Metadata is data about a record or interaction—such as who, when, how large, or which records are related—and may remain visible even when content is ciphertext. [1]

Reviewed 3 primary or first-party sources Written by SealTask

Key points

  • Strong ciphertext should not reveal the protected plaintext without the key.
  • Metadata can reveal patterns even when content remains confidential.
  • Authenticated encryption also detects unauthorized ciphertext modification.
  • A useful privacy claim inventories both encrypted fields and visible fields.

Examples of content and metadata

For a task, the title and description may be encrypted content while creation time, completion state, assignee identifier, record size, and list relationship remain metadata. For a message, the body may be ciphertext while sender, recipient, time, and approximate size remain visible.

The line is architectural, not semantic. A due date could be encrypted in one product and server-visible in another. Metadata can be highly sensitive, so “only metadata” should never be treated as “no privacy impact.”

Why services retain metadata

Servers need some information to authenticate requests, enforce memberships, route updates, sort records, send notifications, enforce quotas, and investigate abuse. Encrypting more metadata can improve privacy, but it may move functionality to clients or require privacy-preserving protocols.

Data minimization asks whether each visible field is actually necessary, how precisely it must be stored, and how long it must be retained.

How to evaluate an encrypted product claim

Look for a field-level description, not a blanket statement. Confirm whether record names, statuses, dates, authorship, file sizes, search indexes, and audit events are encrypted. Then ask whether the provider controls any recovery or escrow key.

Common questions.

Is ciphertext safe to publish?

Not automatically. Safety depends on the algorithm, key secrecy, nonce handling, message format, and the sensitivity of exposed metadata. Ciphertext can also be retained for future attacks. [2]

Can metadata identify a person?

Yes. Identities, social relationships, timing, location, unique sizes, and behavioral patterns can identify or profile people even without plaintext content.

Does encryption hide whether two records are related?

Only if the application also hides or cryptographically protects the relationship. Many services keep database identifiers and relationships visible for routing and authorization.

Primary sources

Definitions prefer standards bodies, government guidance, and the first-party SealTask architecture. Links open the complete source.

  1. 01
    RFC 4949: Internet Security Glossary, Version 2 IETF security terminology, including ciphertext, end-to-end encryption, and threat concepts.
  2. 02
    RFC 8439: ChaCha20 and Poly1305 for IETF Protocols The ChaCha20-Poly1305 AEAD construction and nonce requirements.
  3. 03
    SealTask security architecture Product-specific encryption boundary, server visibility, protocols, and current limitations.

Put the concept to work

Browse the complete learning center