Plain-language explanations of the architecture, cryptography, threats, and compliance terms behind private software—grounded in RFCs, government guidance, and explicit product boundaries.
Start here
Use this center to answer one question at a time, verify the primary source, and follow the related concepts. Product-specific sections explain how SealTask applies each term without turning a general definition into a sales claim.
01
The boundaries behind zero-knowledge and end-to-end encrypted software.
Zero-knowledge architecture
Zero-knowledge architecture is a product design in which protected content is encrypted on a user-controlled device and the service provider does not possess the keys needed to decrypt it. The phrase describes a trust boundary, not an absence of all knowledge: account, billing, security, and operational metadata may still be visible to the service.
Read the explainerEnd-to-end encryption vs encryption at rest
Encryption at rest protects data while it is stored, but the service operating the system may still hold the keys and decrypt it. End-to-end encryption (E2EE) keeps content encrypted between authorized endpoints so intermediaries that carry or store it do not hold the content-decryption keys.
Read the explainerClient-side encryption
Client-side encryption means plaintext is encrypted on the user’s device before it is sent to a service. The service receives ciphertext. Whether this creates an end-to-end or zero-knowledge boundary depends on who controls the keys and whether the provider can cause or observe decryption.
Read the explainerCiphertext 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.
Read the explainer02
The protocols and primitives used to turn a security claim into an architecture.
OPAQUE PAKE
OPAQUE is an augmented password-authenticated key exchange (aPAKE) protocol specified in RFC 9807. It lets a client and server authenticate using a password without sending the password to the server and produces a shared session key after a successful exchange. The server stores a password file, not a reusable plaintext password.
Read the explainerHKDF
HKDF is an HMAC-based key derivation function standardized in RFC 5869. It converts initial keying material into one or more strong, purpose-specific keys through two conceptual stages: Extract concentrates entropy into a pseudorandom key; Expand derives output keys using application context.
Read the explainerHPKE
Hybrid Public Key Encryption (HPKE) is the RFC 9180 framework for encrypting arbitrary-sized plaintexts to a recipient public key. It combines a key encapsulation mechanism (KEM), a key derivation function (KDF), and authenticated encryption (AEAD).
Read the explainerAEAD and ChaCha20-Poly1305
Authenticated Encryption with Associated Data (AEAD) encrypts plaintext and authenticates both the ciphertext and optional unencrypted context. ChaCha20-Poly1305 is the RFC 8439 AEAD that combines the ChaCha20 stream cipher with the Poly1305 authenticator.
Read the explainerArgon2id password hardening
Argon2id is the hybrid Argon2 variant defined in RFC 9106 for password hashing and password-based key derivation. It is deliberately memory-hard and configurable so each password guess consumes meaningful memory and computation.
Read the explainerKey transparency and Merkle trees
Key transparency is a system for recording identity-to-public-key bindings in a verifiable, append-only log. Merkle trees let clients check that a key is included and that a newer log state consistently extends an earlier checkpoint without downloading the entire log.
Read the explainer03
Precise language for understanding account attacks, exposures, and breaches.
Credential stuffing
Credential stuffing is an automated account attack in which username-and-password pairs stolen from one source are tested against other services. It exploits password reuse: the attacker is replaying known credentials, not primarily guessing new passwords.
Read the explainerData breach vs data exposure
A data breach involves unauthorized access to or disclosure of sensitive information. A data exposure describes information made accessible to unintended parties, often through misconfiguration or a product flaw, without necessarily establishing intrusion. Evidence—not headline intensity—should determine the label.
Read the explainer04
What security architecture can support—and what still requires contracts and controls.
Business Associate Agreement (BAA)
A Business Associate Agreement (BAA) is the written contract or arrangement required by the HIPAA Rules when a covered entity or business associate engages another party to create, receive, maintain, or transmit protected health information on its behalf. It allocates permitted uses, safeguards, reporting, subcontractor, access, amendment, accounting, return-or-destruction, and termination duties.
Read the explainerProtected Health Information (PHI)
Protected Health Information (PHI) is individually identifiable health information held or transmitted by a HIPAA covered entity or its business associate, in any form or medium. Electronic PHI (ePHI) is the electronic subset. Context, identity, and the regulated relationship all matter—not only whether a field looks medical.
Read the explainerReference
The vocabulary used across SealTask’s security, guide, comparison, and incident pages. Terms with full explainers link to their canonical page.
Definitions lead with a direct answer, then separate guarantees, limits, and product-specific use. Technical claims prefer RFC Editor, NIST, OWASP, and HHS sources.
Dates change only when content changes. Corrections are welcome at security@sealtask.com.
See how these pieces fit together, including the exact content SealTask cannot read and the operational metadata its servers still process.