@gryt/crypto 0.1.0

package/README.md

@@ -0,0 +1,77 @@
+# @gryt/crypto
+
+Message encryption for [Gryt](https://gryt.chat): key derivation, key bindings,
+sealed envelopes, pinning, and the code two people compare out of band.
+
+Used by the desktop client and the mobile app. They run this, not two ports of
+it — two implementations of one envelope is a pair of clients that send each
+other messages nobody can read, with the sender looking at the text they typed
+either way.
+
+## What it is
+
+- **`dm-keys`** — an X25519 keypair per server, from the same seed the identity
+  comes from, and the shared secret between two of them.
+- **`dm-key-binding`** — a short JWT saying "this message key is mine", signed
+  by the identity key that joined the server.
+- **`message-keys`** — a random key per message, encrypted once for each member.
+- **`peer-keys`** — pin what you saw first, refuse a change.
+- **`member-keys`** — the same decision over a whole member list.
+- **`conversation-encryption`** — every member has a usable key, or nobody gets
+  it sealed.
+- **`comparison-code`** — sixty digits two people read to each other.
+- **`attachments`** — a key per file, bound to its id, with the key inside the
+  sealed message.
+
+## Importing it
+
+Everything is on the barrel, and every module is also its own subpath:
+
+```ts
+import { sealMessage } from "@gryt/crypto";
+import { sealMessage } from "@gryt/crypto/message-keys";
+```
+
+The subpaths exist because the desktop client re-exports this package through
+its own `@/common` barrel alongside a `peer-keys` of its own — the same
+functions with `localStorage` already supplied. Two star exports of one name is
+ambiguous, and TypeScript drops the name rather than saying so, so it takes the
+other modules by subpath and leaves `peer-keys` to its own file.
+
+That makes the file names here part of the published surface.
+`scripts/check-subpaths.mjs` is what stops a rename getting out.
+
+## What it deliberately isn't
+
+**Platform-specific.** No `crypto.subtle`, which React Native does not have. No
+`btoa` or `atob` either — Hermes has them and they stop agreeing with you about
+bytes above `0x7f`, so `base64.ts` does it from the alphabet up. No storage —
+pins go through a `PeerPinStore` the caller supplies. No network, no React, no
+config.
+
+Two exceptions, named where they are: `crypto.getRandomValues`, which every
+target has, and signing a binding, which takes either a WebCrypto key or a
+function, because that is the one place the platforms hold a key differently.
+
+**Hiding that a file exists.** An attachment is encrypted and its name, type and
+dimensions go inside the message, but the server still sees that a file was
+uploaded, how big the ciphertext is, and when. Padding the size is separate work
+and is not pretended at.
+
+**Forward secret.** A message key comes from the seed and never moves, so a seed
+that leaks reads every message ever sent to it. Signal and Matrix ratchet; this
+does not. That is GRYT-754 and it is a different protocol rather than a setting.
+
+**A cryptography library.** The primitives are `@noble/curves`,
+`@noble/hashes` and `@noble/ciphers`. This is the composition of them.
+
+## Checks
+
+`npm test` runs every `scripts/check-*.mjs` against the built `dist`, which is
+what a client installs. `check-crypto-vectors.mjs` holds bytes produced before
+the WebCrypto-to-noble conversion and nothing regenerates them — a change that
+quietly altered the envelope would leave every message already sent unreadable.
+
+## Licence
+
+AGPL-3.0-only.

package/dist/attachments.d.ts

@@ -0,0 +1,57 @@
+export declare const SEALED_ATTACHMENT_TYPE = "gryt-sealed-attachment";
+/**
+ * What a reader needs to open one file, and what a sender knows about it.
+ *
+ * Every field is hidden from the server. `name` and `mime` are what the picker
+ * reported; nothing verifies them, and a client should treat both as text
+ * somebody chose — the same care an unencrypted `original_name` has always
+ * needed.
+ */
+export interface SealedAttachmentKey {
+    /** The file's own key, base64url. */
+    key: string;
+    /** Its nonce, base64url. */
+    iv: string;
+    /** What it was called on the sender's machine. */
+    name?: string;
+    /** What the sender's picker said it was. */
+    mime?: string;
+    /** The plaintext length, so a reader can draw a size before fetching. */
+    size?: number;
+    width?: number;
+    height?: number;
+}
+/**
+ * Encrypt a file, ready to upload.
+ *
+ * The id has to be decided before the bytes are sealed, because it is what they
+ * are bound to. Callers generate one rather than taking the server's: an id
+ * chosen after the upload would mean either re-encrypting or leaving the bytes
+ * unbound, and a server that assigns the id could then assign the same one
+ * twice.
+ */
+export declare function sealAttachment({ bytes, conversationId, fileId, name, mime, width, height, }: {
+    bytes: Uint8Array;
+    conversationId: string;
+    fileId: string;
+    name?: string;
+    mime?: string;
+    width?: number;
+    height?: number;
+}): {
+    ciphertext: Uint8Array<ArrayBuffer>;
+    meta: SealedAttachmentKey;
+};
+/**
+ * Turn the downloaded bytes back into the file.
+ *
+ * Throws when they do not open. There is no ordinary reason for that — unlike a
+ * message, where a member who joined later legitimately has no key — so a
+ * caller should say the file is broken rather than draw an empty one.
+ */
+export declare function openAttachment({ ciphertext, conversationId, fileId, meta, }: {
+    ciphertext: Uint8Array;
+    conversationId: string;
+    fileId: string;
+    meta: SealedAttachmentKey;
+}): Uint8Array<ArrayBuffer>;

package/dist/attachments.js

@@ -0,0 +1,99 @@
+import { gcm } from "@noble/ciphers/aes.js";
+import { base64Url, base64UrlDecode } from "./base64.js";
+/**
+ * A file the server stores and cannot read (GRYT-729 left this out).
+ *
+ * The message body has been unreadable to the server since GRYT-718. The files
+ * hanging off it were not: an upload went up as itself, the server validated
+ * it, made a thumbnail, recorded its name, type and dimensions, and served it
+ * back to anybody with the link. So a conversation could be private and its
+ * photographs public, which is the failure mode where the words are the part
+ * nobody needed.
+ *
+ * ## The shape
+ *
+ * Each file gets its own random key. The bytes are encrypted under it before
+ * they leave the device, and the key — with the real name, type and size —
+ * travels inside the sealed message, encrypted again under that message's
+ * content key. So opening a file needs the message, and opening the message
+ * needs a wrapped key, which is the property the text already had.
+ *
+ * A key per file rather than the message's own content key, because the two
+ * have different lifetimes: an upload happens while somebody is still typing,
+ * and can be cancelled, retried or attached to a different message. Deriving it
+ * from a message that does not exist yet would mean re-encrypting the file when
+ * the draft changed.
+ *
+ * ## What the server still learns
+ *
+ * That a file exists, how big the ciphertext is, and when. Not its name, not
+ * its type, not its contents, and not its dimensions. Padding the size is a
+ * different piece of work and is not pretended at here.
+ *
+ * ## One shot, not a stream
+ *
+ * The whole file is encrypted in memory. Uploads are capped by the server —
+ * 100 MB by default — and the client is already holding the bytes to send them,
+ * so this adds a copy rather than a new problem. A streaming format would be
+ * better for the top of that range and is a different envelope; if it happens,
+ * it happens as a version 2 rather than as a change to this one.
+ */
+const IV_BYTES = 12;
+const FILE_KEY_BYTES = 32;
+export const SEALED_ATTACHMENT_TYPE = "gryt-sealed-attachment";
+function randomBytes(length) {
+    const bytes = new Uint8Array(length);
+    crypto.getRandomValues(bytes);
+    return bytes;
+}
+/**
+ * What the ciphertext is bound to.
+ *
+ * The file id goes in, so the bytes stored under one id cannot be served back
+ * under another and still open. A server that swapped two members' uploads
+ * would otherwise produce files that decrypt perfectly and are the wrong ones —
+ * and since the reader never saw the original, nothing would look wrong.
+ *
+ * The conversation goes in for the reason `message-keys.ts` gives: the same
+ * pair talking in two places must not be able to have a file replayed between
+ * them.
+ */
+function fileContext(conversationId, fileId) {
+    return new TextEncoder().encode(`${SEALED_ATTACHMENT_TYPE}/v1/${conversationId}/${fileId}`);
+}
+/**
+ * Encrypt a file, ready to upload.
+ *
+ * The id has to be decided before the bytes are sealed, because it is what they
+ * are bound to. Callers generate one rather than taking the server's: an id
+ * chosen after the upload would mean either re-encrypting or leaving the bytes
+ * unbound, and a server that assigns the id could then assign the same one
+ * twice.
+ */
+export function sealAttachment({ bytes, conversationId, fileId, name, mime, width, height, }) {
+    const key = randomBytes(FILE_KEY_BYTES);
+    const iv = randomBytes(IV_BYTES);
+    const ciphertext = gcm(key, iv, fileContext(conversationId, fileId)).encrypt(bytes);
+    return {
+        ciphertext: ciphertext,
+        meta: {
+            key: base64Url(key),
+            iv: base64Url(iv),
+            size: bytes.length,
+            ...(name === undefined ? null : { name }),
+            ...(mime === undefined ? null : { mime }),
+            ...(width === undefined ? null : { width }),
+            ...(height === undefined ? null : { height }),
+        },
+    };
+}
+/**
+ * Turn the downloaded bytes back into the file.
+ *
+ * Throws when they do not open. There is no ordinary reason for that — unlike a
+ * message, where a member who joined later legitimately has no key — so a
+ * caller should say the file is broken rather than draw an empty one.
+ */
+export function openAttachment({ ciphertext, conversationId, fileId, meta, }) {
+    return gcm(base64UrlDecode(meta.key), base64UrlDecode(meta.iv), fileContext(conversationId, fileId)).decrypt(ciphertext);
+}

package/dist/base64.d.ts

@@ -0,0 +1,27 @@
+/**
+ * base64url, without `btoa` and `atob`.
+ *
+ * Every module here used to carry its own two-line pair built on the host's
+ * base64: a string assembled one `String.fromCharCode` at a time, handed to
+ * `btoa`. That is fine in a browser and it is what the client did for a year.
+ *
+ * It is not safe on Hermes, and the mobile app's own `encoding.ts` says so in a
+ * comment written by somebody who hit it — a byte above `0x7f` and the engine's
+ * idea of a binary string stops matching yours. This package exists so the two
+ * clients run one implementation, so it cannot be the one that only works on
+ * one of them. Bytes in, ASCII out, no globals involved.
+ *
+ * Byte-for-byte identical to what `btoa` produced. `check-crypto-vectors.mjs`
+ * holds envelopes from before this file existed and is what says so.
+ */
+export declare function base64Url(bytes: Uint8Array): string;
+/**
+ * Takes either alphabet and padding or none of it.
+ *
+ * The callers disagreed about this before they shared a decoder: one stripped
+ * `+/` into `-_` and passed whatever padding arrived to `atob`, the other did
+ * not. Both shapes turn up — a binding is unpadded and a wrapped key is written
+ * by this file — so accepting both is the honest reading rather than a
+ * convenience.
+ */
+export declare function base64UrlDecode(value: string): Uint8Array<ArrayBuffer>;

package/dist/base64.js

@@ -0,0 +1,66 @@
+/**
+ * base64url, without `btoa` and `atob`.
+ *
+ * Every module here used to carry its own two-line pair built on the host's
+ * base64: a string assembled one `String.fromCharCode` at a time, handed to
+ * `btoa`. That is fine in a browser and it is what the client did for a year.
+ *
+ * It is not safe on Hermes, and the mobile app's own `encoding.ts` says so in a
+ * comment written by somebody who hit it — a byte above `0x7f` and the engine's
+ * idea of a binary string stops matching yours. This package exists so the two
+ * clients run one implementation, so it cannot be the one that only works on
+ * one of them. Bytes in, ASCII out, no globals involved.
+ *
+ * Byte-for-byte identical to what `btoa` produced. `check-crypto-vectors.mjs`
+ * holds envelopes from before this file existed and is what says so.
+ */
+const ALPHABET = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
+export function base64Url(bytes) {
+    let out = "";
+    for (let i = 0; i < bytes.length; i += 3) {
+        const a = bytes[i];
+        const b = i + 1 < bytes.length ? bytes[i + 1] : undefined;
+        const c = i + 2 < bytes.length ? bytes[i + 2] : undefined;
+        out += ALPHABET[a >> 2];
+        out += ALPHABET[((a & 0x03) << 4) | ((b ?? 0) >> 4)];
+        if (b === undefined)
+            break;
+        out += ALPHABET[((b & 0x0f) << 2) | ((c ?? 0) >> 6)];
+        if (c === undefined)
+            break;
+        out += ALPHABET[c & 0x3f];
+    }
+    // Unpadded, which is what base64url means in a JWT.
+    return out;
+}
+const LOOKUP = new Map();
+for (let i = 0; i < ALPHABET.length; i++)
+    LOOKUP.set(ALPHABET[i], i);
+/**
+ * Takes either alphabet and padding or none of it.
+ *
+ * The callers disagreed about this before they shared a decoder: one stripped
+ * `+/` into `-_` and passed whatever padding arrived to `atob`, the other did
+ * not. Both shapes turn up — a binding is unpadded and a wrapped key is written
+ * by this file — so accepting both is the honest reading rather than a
+ * convenience.
+ */
+export function base64UrlDecode(value) {
+    const clean = value.replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");
+    const out = new Uint8Array(Math.floor((clean.length * 6) / 8));
+    let bits = 0;
+    let acc = 0;
+    let written = 0;
+    for (const ch of clean) {
+        const digit = LOOKUP.get(ch);
+        if (digit === undefined)
+            throw new Error("Not base64url");
+        acc = (acc << 6) | digit;
+        bits += 6;
+        if (bits >= 8) {
+            bits -= 8;
+            out[written++] = (acc >> bits) & 0xff;
+        }
+    }
+    return out.subarray(0, written);
+}

package/dist/comparison-code.d.ts

@@ -0,0 +1,58 @@
+/**
+ * A code two people read to each other (GRYT-730).
+ *
+ * Everything since GRYT-720 catches a key that *changed*. None of it can say
+ * the first key was ever the right one, because the server is what introduced
+ * the two people and no check made through the server gets past that. This is
+ * the way out, and it is the only one: two people compare a short string over
+ * something the server is not on — a phone call, a doorway — and if it matches,
+ * neither of them is talking to the server.
+ *
+ * ## What goes into it
+ *
+ * Everything both sides have pinned about each other: both identity
+ * thumbprints and both DM public keys. A server that substituted any one of the
+ * four makes the two codes differ, and there is nothing it can do about that
+ * because it never sees the comparison.
+ *
+ * The four are sorted before hashing, so both people compute the same code
+ * without having to agree on who is first. That is the whole reason for the
+ * sort, and it is why the two halves are labelled rather than positional.
+ *
+ * ## What it cannot say
+ *
+ * Whose keys they are. Matching codes mean the two of you hold the keys you
+ * think you hold; they say nothing about the nickname on the other end, and a
+ * code compared with the wrong person matches perfectly. That is not a gap this
+ * can close and no design closes it — at some point somebody recognises a voice.
+ *
+ * ## Digits, deliberately
+ *
+ * Not words. `identity-seed.ts` already renders 24 words from the BIP39 list
+ * for the identity backup, and eight more words on a card beside it would read
+ * as a second recovery phrase. The one thing this must never be mistaken for is
+ * something worth typing into a box or keeping secret — it is public, and it is
+ * meant to be read out loud.
+ */
+/**
+ * Sixty digits is a little under 200 bits, which is far more than the work of
+ * grinding a key to match matters at — the number is chosen for reading aloud
+ * rather than for the margin. Twelve groups of five is what fits a card in
+ * three rows and what somebody can keep their place in halfway down a phone
+ * call.
+ */
+export declare const COMPARISON_CODE_DIGITS: number;
+export interface ComparisonSide {
+    /** Their identity key's JWK thumbprint, as pinned. */
+    thumbprint: string;
+    /** Their DM public key, base64url, as pinned. */
+    dmPublicKey: string;
+}
+/**
+ * The code for one pair.
+ *
+ * Both sides go in, sorted, so the two people compute the same string. Neither
+ * has to know which of them is "first", and there is no ordering rule to get
+ * wrong on one platform and right on another.
+ */
+export declare function comparisonCode(a: ComparisonSide, b: ComparisonSide): string;

package/dist/comparison-code.js

@@ -0,0 +1,105 @@
+/**
+ * A code two people read to each other (GRYT-730).
+ *
+ * Everything since GRYT-720 catches a key that *changed*. None of it can say
+ * the first key was ever the right one, because the server is what introduced
+ * the two people and no check made through the server gets past that. This is
+ * the way out, and it is the only one: two people compare a short string over
+ * something the server is not on — a phone call, a doorway — and if it matches,
+ * neither of them is talking to the server.
+ *
+ * ## What goes into it
+ *
+ * Everything both sides have pinned about each other: both identity
+ * thumbprints and both DM public keys. A server that substituted any one of the
+ * four makes the two codes differ, and there is nothing it can do about that
+ * because it never sees the comparison.
+ *
+ * The four are sorted before hashing, so both people compute the same code
+ * without having to agree on who is first. That is the whole reason for the
+ * sort, and it is why the two halves are labelled rather than positional.
+ *
+ * ## What it cannot say
+ *
+ * Whose keys they are. Matching codes mean the two of you hold the keys you
+ * think you hold; they say nothing about the nickname on the other end, and a
+ * code compared with the wrong person matches perfectly. That is not a gap this
+ * can close and no design closes it — at some point somebody recognises a voice.
+ *
+ * ## Digits, deliberately
+ *
+ * Not words. `identity-seed.ts` already renders 24 words from the BIP39 list
+ * for the identity backup, and eight more words on a card beside it would read
+ * as a second recovery phrase. The one thing this must never be mistaken for is
+ * something worth typing into a box or keeping secret — it is public, and it is
+ * meant to be read out loud.
+ */
+import { sha256 } from "@noble/hashes/sha2.js";
+/** How many digits, and why that many. */
+const GROUPS = 12;
+const DIGITS_PER_GROUP = 5;
+/**
+ * Sixty digits is a little under 200 bits, which is far more than the work of
+ * grinding a key to match matters at — the number is chosen for reading aloud
+ * rather than for the margin. Twelve groups of five is what fits a card in
+ * three rows and what somebody can keep their place in halfway down a phone
+ * call.
+ */
+export const COMPARISON_CODE_DIGITS = GROUPS * DIGITS_PER_GROUP;
+/**
+ * Enough bytes for one digit each, from a hash that only produces 32.
+ *
+ * Counting rather than wrapping. Wrapping a 32-byte digest around 60 digits
+ * repeats the first 28 of them at the end, which halves what the code actually
+ * distinguishes and — worse — is visible: the printed code has a run in it that
+ * looks like a bug and invites somebody to stop comparing.
+ */
+function stretch(seed, count) {
+    const out = new Uint8Array(count);
+    for (let block = 0; block * 32 < count; block++) {
+        const chunk = sha256(new Uint8Array([...seed, block]));
+        out.set(chunk.subarray(0, Math.min(32, count - block * 32)), block * 32);
+    }
+    return out;
+}
+function digitsFrom(bytes, count) {
+    // Every digit from its own byte, taken modulo ten. That is very slightly
+    // biased — 256 is not a multiple of 10 — and it does not matter here: this is
+    // a fingerprint to compare, not a secret to guess. Rejection sampling would
+    // buy a fraction of a bit and a branch that is hard to test.
+    let out = "";
+    for (let i = 0; i < count; i++)
+        out += (bytes[i] % 10).toString();
+    return out;
+}
+/**
+ * The code for one pair.
+ *
+ * Both sides go in, sorted, so the two people compute the same string. Neither
+ * has to know which of them is "first", and there is no ordering rule to get
+ * wrong on one platform and right on another.
+ */
+export function comparisonCode(a, b) {
+    const halves = [
+        [a.thumbprint, a.dmPublicKey],
+        [b.thumbprint, b.dmPublicKey],
+    ]
+        .map((half) => JSON.stringify(half))
+        .sort();
+    /*
+     * JSON rather than joining on a separator.
+     *
+     * `thumbprint + ":" + key` is ambiguous: a thumbprint of "a" with a key of
+     * "b:c" and a thumbprint of "a:b" with a key of "c" produce the same string,
+     * so two different pairs of keys get the same code. Neither field contains a
+     * colon today — both are base64url — which makes it the kind of thing that is
+     * fine until somebody changes what goes in here. Quoting removes the question.
+     */
+    const digest = sha256(new TextEncoder().encode(JSON.stringify(halves)));
+    const digits = digitsFrom(stretch(digest, COMPARISON_CODE_DIGITS), COMPARISON_CODE_DIGITS);
+    const groups = [];
+    for (let i = 0; i < COMPARISON_CODE_DIGITS; i += DIGITS_PER_GROUP) {
+        groups.push(digits.slice(i, i + DIGITS_PER_GROUP));
+    }
+    return groups.join(" ");
+}

package/dist/conversation-encryption.d.ts

@@ -0,0 +1,116 @@
+/**
+ * Whether a conversation can be encrypted, and doing it (GRYT-729).
+ *
+ * Everything underneath this has existed for a while and had no caller.
+ * `sealMessage` since GRYT-718, keys published and pinned since GRYT-727. This
+ * is the decision that turns them on, and it is a decision rather than a
+ * capability check: it can say no, and when it says no the answer has to reach
+ * the person about to press send.
+ *
+ * ## Every member, or nobody
+ *
+ * A message is sealed only when every member of the conversation has a key this
+ * client is willing to use. One member without one is not a reason to seal for
+ * the rest — they would be unable to read a conversation they are in, silently,
+ * and the sender would have no idea.
+ *
+ * A member whose key *changed* counts as not having one. That is the refusal
+ * from GRYT-726 arriving where it matters: nothing is encrypted to a key this
+ * client has decided not to trust, and nothing falls back to plaintext without
+ * saying so either.
+ *
+ * ## Saying no out loud
+ *
+ * {@link SealDecision} carries who is missing and why. A composer that quietly
+ * sends in the clear because somebody has not updated their client is the exact
+ * failure this whole design exists to avoid, and it is invisible from the
+ * outside — the message sends, it arrives, it reads normally.
+ */
+import type { SealedAttachmentKey } from "./attachments.js";
+import { type OpenedMessage } from "./message-keys.js";
+import { type PeerKeyDecision } from "./peer-keys.js";
+export interface ConversationMember {
+    /** `server_user_id`, which is how the conversation names them. */
+    memberId: string;
+    /** What this client decided about their key, from `evaluateMemberKeys`. */
+    keyState?: {
+        decision: PeerKeyDecision;
+    } | undefined;
+}
+export type SealDecision = {
+    kind: "seal";
+    recipients: {
+        memberId: string;
+        publicKey: Uint8Array;
+    }[];
+} | {
+    kind: "plaintext";
+    /**
+     * Why, per member, so a composer can name them rather than saying
+     * "encryption unavailable" and leaving somebody to guess.
+     */
+    blockedBy: {
+        memberId: string;
+        reason: "no-key" | "changed" | "unusable";
+    }[];
+};
+/**
+ * Can this conversation be sealed, and to whom.
+ *
+ * `self` is included in the recipients, because a sender who cannot read their
+ * own message back has sent something they will look at tomorrow and find
+ * empty. `sealMessage` refuses a recipient list without them for that reason;
+ * this is where they are put in.
+ */
+export declare function decideSealing({ members, self, }: {
+    /** Everybody in the conversation apart from you. */
+    members: ConversationMember[];
+    /** Your own member id and DM public key on this server. */
+    self: {
+        memberId: string;
+        publicKey: Uint8Array;
+    } | null;
+}): SealDecision;
+/**
+ * Seal a message for a conversation, or say why it cannot be.
+ *
+ * Returns the envelope as the string that goes on the wire. Null means send it
+ * in the clear — and a caller that ignores which of the two it got is back to
+ * sending plaintext without telling anybody.
+ */
+export declare function sealForConversation({ plaintext, conversationId, senderKeys, decision, attachments, }: {
+    plaintext: string;
+    conversationId: string;
+    senderKeys: {
+        privateKey: Uint8Array;
+        publicKey: Uint8Array;
+    };
+    decision: SealDecision;
+    /**
+     * File id to what `sealAttachment` returned for it (GRYT-729).
+     *
+     * A conversation that cannot be sealed returns null here, and a caller that
+     * has already encrypted and uploaded files then has an upload nobody can
+     * open. Encrypt the files *after* checking `decision.kind`, not before.
+     */
+    attachments?: Record<string, SealedAttachmentKey>;
+}): Promise<string | null>;
+/**
+ * Read one back.
+ *
+ * Null when there is no wrapped key for this member — somebody who joined after
+ * it was sent — which a client draws as a message it cannot read rather than as
+ * an error. Anything else throws, because a key that is present and does not
+ * open means tampering or the wrong conversation, and an empty bubble would
+ * hide it.
+ */
+export declare function openForConversation({ sealed, conversationId, memberId, recipientKeys, }: {
+    /** The string off the wire. */
+    sealed: string;
+    conversationId: string;
+    memberId: string;
+    recipientKeys: {
+        privateKey: Uint8Array;
+        publicKey: Uint8Array;
+    };
+}): Promise<OpenedMessage | null>;