@gryt/crypto 0.1.0

package/dist/conversation-encryption.js

@@ -0,0 +1,111 @@
+/**
+ * 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 { openMessage, sealMessage, } from "./message-keys.js";
+/**
+ * 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 function decideSealing({ members, self, }) {
+    if (!self) {
+        // No key of our own means nothing to seal with, which is a device that has
+        // not finished joining rather than a problem with anybody else.
+        return { kind: "plaintext", blockedBy: [] };
+    }
+    const recipients = [
+        { memberId: self.memberId, publicKey: self.publicKey },
+    ];
+    const blockedBy = [];
+    for (const member of members) {
+        const decision = member.keyState?.decision;
+        if (!decision || decision.kind === "none") {
+            blockedBy.push({ memberId: member.memberId, reason: "no-key" });
+            continue;
+        }
+        if (decision.kind === "unusable") {
+            blockedBy.push({ memberId: member.memberId, reason: "unusable" });
+            continue;
+        }
+        if (decision.kind === "changed") {
+            // The refusal from GRYT-726, arriving where it costs something. Falling
+            // back to plaintext here is the honest answer; encrypting to the new key
+            // would be pretending the change was fine.
+            blockedBy.push({ memberId: member.memberId, reason: "changed" });
+            continue;
+        }
+        recipients.push({
+            memberId: member.memberId,
+            publicKey: decision.verified.dmPublicKey,
+        });
+    }
+    if (blockedBy.length > 0)
+        return { kind: "plaintext", blockedBy };
+    return { kind: "seal", recipients };
+}
+/**
+ * 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 async function sealForConversation({ plaintext, conversationId, senderKeys, decision, attachments, }) {
+    if (decision.kind !== "seal")
+        return null;
+    const sealed = await sealMessage({
+        plaintext,
+        conversationId,
+        senderKeys,
+        recipients: decision.recipients,
+        attachments,
+    });
+    return JSON.stringify(sealed);
+}
+/**
+ * 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 async function openForConversation({ sealed, conversationId, memberId, recipientKeys, }) {
+    let envelope;
+    try {
+        envelope = JSON.parse(sealed);
+    }
+    catch {
+        throw new Error("That message is not a sealed envelope.");
+    }
+    return openMessage({ sealed: envelope, conversationId, memberId, recipientKeys });
+}

package/dist/dm-key-binding.d.ts

@@ -0,0 +1,93 @@
+/**
+ * Saying that a DM key and an identity key belong to the same person (GRYT-720).
+ *
+ * `dm-keys.ts` derives the key a message is encrypted to. Nothing says whose it
+ * is, and a key handed over by a server that could have made it up is worth
+ * nothing — a server that wanted to read a conversation would give each side its
+ * own key and relay.
+ *
+ * This is one link of the chain that answers that: a short JWT, signed by the
+ * per-server identity key, saying "this DM public key is mine, on this server".
+ *
+ * ## What it proves, exactly
+ *
+ * That whoever holds the identity key also chose this DM key. Nothing else. In
+ * particular it does **not** say whose identity key it is — the public half
+ * rides in the header, so a server can mint a keypair and sign a perfectly
+ * valid binding with it.
+ *
+ * That is not a hole in this file, it is where the problem actually lives.
+ * Nothing verifiable in band can say who a key belongs to; the regress stops at
+ * something pinned earlier or something compared out of band, and at nothing
+ * else. What this buys is that the two keys are now one thing to substitute
+ * instead of two, and the identity key is the one the server challenged at join
+ * — so a server handing out a forged binding is contradicting a proof it
+ * verified itself, in front of every member at once.
+ *
+ * The caller pins {@link VerifiedDmKeyBinding.identityThumbprint}. That is the
+ * part that means something, and `server-pins.ts` already does the same three
+ * moves for server keys: pin on first sight, detect a change, refuse it.
+ *
+ * ## Why the key is inside the signed statement
+ *
+ * A server storing a DM key and a signature as two fields could serve one
+ * person's key with another's signature, and a client checking them separately
+ * might not notice. There is one field: the binding. The key is read out of it
+ * after the signature verifies, or it is not read at all.
+ */
+import { type IdentityScope } from "./scope.js";
+export interface VerifiedDmKeyBinding {
+    /** The X25519 public key, raw bytes, once the signature has been checked. */
+    dmPublicKey: Uint8Array<ArrayBuffer>;
+    /**
+     * The identity key that signed this, as a JWK thumbprint.
+     *
+     * **This is the thing to pin.** Everything else in here is a statement by
+     * whoever holds that key, and is worth exactly what the key is worth.
+     */
+    identityThumbprint: string;
+    /** The scope the binding claims, already checked against the expected one. */
+    scope: IdentityScope;
+    /** When it was signed, seconds since the epoch. */
+    signedAt: number;
+}
+/**
+ * Sign the statement.
+ *
+ * There is no expiry. The DM key is derived from the seed and the scope, so it
+ * does not roll and a binding does not go stale — and an expiry a client cannot
+ * renew while offline would make old messages unreadable for a reason that has
+ * nothing to do with anybody's keys. `signedAt` is there so a verifier can
+ * prefer the newer of two bindings if one ever does change, which is a
+ * different question from whether this one is still good.
+ */
+export declare function signDmKeyBinding({ dmPublicKey, scope, identityPrivateKey, identityPublicJwk, now, }: {
+    dmPublicKey: Uint8Array;
+    scope: IdentityScope;
+    /**
+     * A `CryptoKey`, or a function that signs bytes with the identity key.
+     *
+     * Two shapes because the two clients hold the key differently: the desktop
+     * has a WebCrypto handle, and React Native has raw bytes and a curve library
+     * (GRYT-733). Verifying is pure and shared — every client does it for every
+     * peer — while signing happens once, with your own key, and is the one place
+     * the platforms genuinely differ.
+     */
+    identityPrivateKey: CryptoKey | ((bytes: Uint8Array) => Promise<Uint8Array>);
+    /** Rides in the header, so a verifier that has never seen it can check. */
+    identityPublicJwk: JsonWebKey;
+    now?: number;
+}): Promise<string>;
+/**
+ * Check a binding, and refuse it rather than returning something partly checked.
+ *
+ * Throws on anything wrong. There is no "probably fine" here: a caller that got
+ * a value back has a DM key whose signature verified under the thumbprint it was
+ * handed, and a caller that did not has nothing to think about.
+ *
+ * `expectedScope` is required. Without it a binding signed for one server can be
+ * replayed by another, which is the cheapest attack available to any operator
+ * who can see a member list — and the scope is the one thing the verifier
+ * already knows for certain, because it is the server it is talking to.
+ */
+export declare function verifyDmKeyBinding(binding: string, expectedScope: IdentityScope): Promise<VerifiedDmKeyBinding>;

package/dist/dm-key-binding.js

@@ -0,0 +1,208 @@
+/**
+ * Saying that a DM key and an identity key belong to the same person (GRYT-720).
+ *
+ * `dm-keys.ts` derives the key a message is encrypted to. Nothing says whose it
+ * is, and a key handed over by a server that could have made it up is worth
+ * nothing — a server that wanted to read a conversation would give each side its
+ * own key and relay.
+ *
+ * This is one link of the chain that answers that: a short JWT, signed by the
+ * per-server identity key, saying "this DM public key is mine, on this server".
+ *
+ * ## What it proves, exactly
+ *
+ * That whoever holds the identity key also chose this DM key. Nothing else. In
+ * particular it does **not** say whose identity key it is — the public half
+ * rides in the header, so a server can mint a keypair and sign a perfectly
+ * valid binding with it.
+ *
+ * That is not a hole in this file, it is where the problem actually lives.
+ * Nothing verifiable in band can say who a key belongs to; the regress stops at
+ * something pinned earlier or something compared out of band, and at nothing
+ * else. What this buys is that the two keys are now one thing to substitute
+ * instead of two, and the identity key is the one the server challenged at join
+ * — so a server handing out a forged binding is contradicting a proof it
+ * verified itself, in front of every member at once.
+ *
+ * The caller pins {@link VerifiedDmKeyBinding.identityThumbprint}. That is the
+ * part that means something, and `server-pins.ts` already does the same three
+ * moves for server keys: pin on first sight, detect a change, refuse it.
+ *
+ * ## Why the key is inside the signed statement
+ *
+ * A server storing a DM key and a signature as two fields could serve one
+ * person's key with another's signature, and a client checking them separately
+ * might not notice. There is one field: the binding. The key is read out of it
+ * after the signature verifies, or it is not read at all.
+ */
+/*
+ * The `.ts` is for Node's type stripping, which `check-dm-key-binding.mjs` runs
+ * this file through and which does no extension inference. `message-keys.ts`
+ * carries the same one for the same reason; `dm-keys.ts` does not, because its
+ * import from here is type-only and erases.
+ */
+import { p256 } from "@noble/curves/nist.js";
+import { sha256 } from "@noble/hashes/sha2.js";
+import { base64Url, base64UrlDecode } from "./base64.js";
+import { asIdentityScope } from "./scope.js";
+import { jwkThumbprint } from "./thumbprint.js";
+/**
+ * The `iss` a binding carries.
+ *
+ * Constant rather than the signer's own id, because a binding is not addressed
+ * to a server and has no subject to name. What it is *for* is the thing worth
+ * writing down, so a JWT that arrives on this path and says something else is
+ * refused rather than read hopefully.
+ */
+const BINDING_ISSUER = "gryt:dm-key";
+/**
+ * A JWK's public point as the uncompressed bytes the curve library takes.
+ *
+ * `0x04`, then x, then y — the same layout `identity-seed.ts` slices apart when
+ * it builds a JWK from a derived key, put back together.
+ */
+function jwkToPoint(jwk) {
+    if (jwk.kty !== "EC" || jwk.crv !== "P-256") {
+        throw new Error("A DM key binding is signed with a P-256 key.");
+    }
+    if (typeof jwk.x !== "string" || typeof jwk.y !== "string") {
+        throw new Error("That DM key binding's key has no coordinates.");
+    }
+    const x = base64UrlDecode(jwk.x);
+    const y = base64UrlDecode(jwk.y);
+    if (x.length !== 32 || y.length !== 32) {
+        throw new Error("A P-256 coordinate is 32 bytes.");
+    }
+    const point = new Uint8Array(65);
+    point[0] = 0x04;
+    point.set(x, 1);
+    point.set(y, 33);
+    return point;
+}
+function utf8(value) {
+    return new TextEncoder().encode(value);
+}
+/**
+ * Sign the statement.
+ *
+ * There is no expiry. The DM key is derived from the seed and the scope, so it
+ * does not roll and a binding does not go stale — and an expiry a client cannot
+ * renew while offline would make old messages unreadable for a reason that has
+ * nothing to do with anybody's keys. `signedAt` is there so a verifier can
+ * prefer the newer of two bindings if one ever does change, which is a
+ * different question from whether this one is still good.
+ */
+export async function signDmKeyBinding({ dmPublicKey, scope, identityPrivateKey, identityPublicJwk, now = Math.floor(Date.now() / 1000), }) {
+    const header = {
+        alg: "ES256",
+        typ: "JWT",
+        jwk: identityPublicJwk,
+    };
+    const payload = {
+        iss: BINDING_ISSUER,
+        scope,
+        dm: base64Url(dmPublicKey),
+        iat: now,
+    };
+    const signingInput = `${base64Url(utf8(JSON.stringify(header)))}.${base64Url(utf8(JSON.stringify(payload)))}`;
+    const bytes = utf8(signingInput);
+    const signature = typeof identityPrivateKey === "function"
+        ? await identityPrivateKey(bytes)
+        : new Uint8Array(await crypto.subtle.sign({ name: "ECDSA", hash: "SHA-256" }, identityPrivateKey, bytes));
+    return `${signingInput}.${base64Url(signature)}`;
+}
+/**
+ * Check a binding, and refuse it rather than returning something partly checked.
+ *
+ * Throws on anything wrong. There is no "probably fine" here: a caller that got
+ * a value back has a DM key whose signature verified under the thumbprint it was
+ * handed, and a caller that did not has nothing to think about.
+ *
+ * `expectedScope` is required. Without it a binding signed for one server can be
+ * replayed by another, which is the cheapest attack available to any operator
+ * who can see a member list — and the scope is the one thing the verifier
+ * already knows for certain, because it is the server it is talking to.
+ */
+export async function verifyDmKeyBinding(binding, expectedScope) {
+    const parts = binding.split(".");
+    if (parts.length !== 3) {
+        throw new Error("A DM key binding is a compact JWT with three parts.");
+    }
+    let header;
+    let payload;
+    try {
+        header = JSON.parse(new TextDecoder().decode(base64UrlDecode(parts[0])));
+        payload = JSON.parse(new TextDecoder().decode(base64UrlDecode(parts[1])));
+    }
+    catch {
+        throw new Error("That DM key binding is not readable.");
+    }
+    // Pinned rather than read off the header. `alg: "none"` is the oldest JWT bug
+    // there is, and every softer version of it — accepting HS256 and verifying
+    // the signature with the public key as the HMAC secret — starts with taking
+    // the algorithm from the attacker.
+    if (header.alg !== "ES256" || header.typ !== "JWT") {
+        throw new Error("A DM key binding is ES256, and this one says otherwise.");
+    }
+    const jwk = header.jwk;
+    if (!jwk || typeof jwk !== "object") {
+        throw new Error("That DM key binding carries no key to check it with.");
+    }
+    if (jwk.d !== undefined) {
+        throw new Error("That DM key binding carries private key material.");
+    }
+    if (payload.iss !== BINDING_ISSUER) {
+        throw new Error(`A DM key binding is issued by ${BINDING_ISSUER}.`);
+    }
+    if (payload.scope !== expectedScope) {
+        // Replay from another server. The binding is perfectly valid there.
+        throw new Error("That DM key binding was signed for a different server.");
+    }
+    if (typeof payload.dm !== "string" || typeof payload.iat !== "number") {
+        throw new Error("That DM key binding is missing a key or a time.");
+    }
+    /*
+     * Verified with the curve library rather than the platform (GRYT-733).
+     *
+     * `crypto.subtle` is not on React Native and this file has to run there
+     * unchanged. The signature is the same either way: ES256 is P-256 over a
+     * SHA-256 digest with a raw sixty-four byte `r || s`, which is what WebCrypto
+     * emits and what `p256.verify` takes.
+     */
+    const publicKey = jwkToPoint(jwk);
+    const signature = base64UrlDecode(parts[2]);
+    if (signature.length !== 64) {
+        throw new Error("A DM key binding's signature is 64 bytes.");
+    }
+    /*
+     * `lowS: false`, and this is not a relaxation.
+     *
+     * ECDSA has two valid signatures for every message — `s` and `order - s` —
+     * and noble refuses the high one by default, because for a blockchain a
+     * signature that can be rewritten while staying valid is a transaction that
+     * can be replayed under a second id. Nothing here is identified by its
+     * signature.
+     *
+     * WebCrypto does not normalise, JOSE does not require it, and roughly half of
+     * all ES256 signatures come out high. Leaving the default on would have
+     * rejected about half of every client's bindings, at random, with the message
+     * that the signature did not check out — and the other half would have worked
+     * perfectly, which is the shape of bug that survives a lot of testing.
+     */
+    const ok = p256.verify(signature, sha256(utf8(`${parts[0]}.${parts[1]}`)), publicKey, { prehash: false, lowS: false });
+    if (!ok) {
+        throw new Error("That DM key binding's signature does not check out.");
+    }
+    const dmPublicKey = base64UrlDecode(payload.dm);
+    // X25519 public keys are 32 bytes. Anything else is not one, and passing it
+    // to the curve library would be the place that found out.
+    if (dmPublicKey.length !== 32) {
+        throw new Error(`A DM public key is 32 bytes, and this one is ${dmPublicKey.length}.`);
+    }
+    return {
+        dmPublicKey,
+        identityThumbprint: jwkThumbprint(jwk),
+        scope: asIdentityScope(payload.scope),
+        signedAt: payload.iat,
+    };
+}

package/dist/dm-keys.d.ts

@@ -0,0 +1,89 @@
+/**
+ * The key a direct message is encrypted to (GRYT-709).
+ *
+ * Separate from the identity key on purpose, and not because it is tidier. The
+ * identity key is ECDSA P-256, which signs and cannot do key agreement — there
+ * is no operation that turns two ECDSA keys into a shared secret. Encryption
+ * needs a curve built for agreement, so this is X25519 and it is a second key.
+ *
+ * ## Nothing secret ever leaves the device
+ *
+ * Only {@link dmPublicKey} is published. The private half is derived here, used
+ * here, and never sent anywhere — not to the server, not encrypted, not as part
+ * of a backup. A server that wanted to read a conversation would have to obtain
+ * something that has never been transmitted.
+ *
+ * What *is* backed up is the seed, which the 24-word phrase already carries. So
+ * restoring an identity restores the ability to read old messages, without
+ * anything about the messages being stored anywhere but the server that already
+ * has them.
+ *
+ * ## One key per server, like the identity key
+ *
+ * `identity-seed.ts` derives a separate key for each server so that two of them
+ * cannot tell they are talking to the same person. That property is worth
+ * exactly as much here, and would be undone by a single DM key shared across
+ * servers — so the same scope goes into the derivation.
+ *
+ * **The scope, not the address (GRYT-719).** `identityScopeFor` gives the
+ * server's lineage id, and only falls back to the address for a server that
+ * proved nothing. Deriving from the address instead would give a server on a
+ * LAN address and a tunnel two DM keys, and would change the key whenever a
+ * port is taken or a lease moves. For the identity key that bug meant arriving
+ * as a stranger, which GRYT-257 fixed and which is at least visible. Here it
+ * would mean every message ever encrypted to the old key is unreadable, with
+ * nothing logged. `IdentityScope` is branded so the wrong string does not
+ * typecheck.
+ *
+ * The consequence is that a conversation is bound to the server it happens on,
+ * which is what `useDirectMessages.ts` and `conversations.ts` already say about
+ * DMs in plaintext. Encryption does not change the shape, it enforces it.
+ *
+ * ## What this file does not do
+ *
+ * It derives a keypair and computes a shared secret. It does not publish the
+ * public key, does not encrypt a message, and does not know what a conversation
+ * is. Wrapping a per-message key for each member, and the certificate that says
+ * whose public key is whose, are the parts that follow — and the certificate is
+ * the one that decides whether any of this is worth anything, because a shared
+ * secret with a key the server chose for you protects nothing.
+ */
+import type { IdentityScope } from "./scope.js";
+export interface DmKeyPair {
+    /** Never leaves this device. Not sent, not backed up, not logged. */
+    privateKey: Uint8Array;
+    /** The half that is published, so others can encrypt to you. */
+    publicKey: Uint8Array;
+}
+/**
+ * The DM keypair this seed gives for one server.
+ *
+ * Deterministic: the same seed and scope give the same keypair on any device,
+ * which is what makes the recovery phrase enough to read old conversations
+ * again — and, because the scope outlives an address change, what makes them
+ * still readable after the server moves.
+ *
+ * Raw bytes rather than a `CryptoKey`, because WebCrypto's X25519 support is
+ * younger than the browsers Gryt runs on and the agreement below is done by the
+ * curve library anyway. There is nothing to gain from importing a key into an
+ * API that is not going to perform the operation.
+ */
+export declare function deriveDmKeyPair(seed: Uint8Array, scope: IdentityScope): DmKeyPair;
+/** The public half alone, for the cases that should not touch the private one. */
+export declare function dmPublicKey(seed: Uint8Array, scope: IdentityScope): Uint8Array;
+/**
+ * The secret two people share, from one private half and one public half.
+ *
+ * Run through HKDF rather than used raw. The X25519 output is a curve point's
+ * x-coordinate, which is not uniformly distributed over 32 bytes, and a key
+ * derivation function is what turns it into something safe to use as one. The
+ * conversation id goes in as `info`, so the same pair of people talking in two
+ * conversations do not derive the same key in both.
+ *
+ * **This is not enough on its own, and the gap is not in the maths.** Agreement
+ * with the wrong public key succeeds exactly as well as agreement with the right
+ * one — both produce a perfectly good secret. Whether `theirPublicKey` belongs
+ * to the person named beside it is the question the certificate answers, and
+ * until that exists a caller is trusting the server for it.
+ */
+export declare function dmSharedSecret(privateKey: Uint8Array, theirPublicKey: Uint8Array, conversationId: string): Uint8Array;

package/dist/dm-keys.js

@@ -0,0 +1,142 @@
+/**
+ * The key a direct message is encrypted to (GRYT-709).
+ *
+ * Separate from the identity key on purpose, and not because it is tidier. The
+ * identity key is ECDSA P-256, which signs and cannot do key agreement — there
+ * is no operation that turns two ECDSA keys into a shared secret. Encryption
+ * needs a curve built for agreement, so this is X25519 and it is a second key.
+ *
+ * ## Nothing secret ever leaves the device
+ *
+ * Only {@link dmPublicKey} is published. The private half is derived here, used
+ * here, and never sent anywhere — not to the server, not encrypted, not as part
+ * of a backup. A server that wanted to read a conversation would have to obtain
+ * something that has never been transmitted.
+ *
+ * What *is* backed up is the seed, which the 24-word phrase already carries. So
+ * restoring an identity restores the ability to read old messages, without
+ * anything about the messages being stored anywhere but the server that already
+ * has them.
+ *
+ * ## One key per server, like the identity key
+ *
+ * `identity-seed.ts` derives a separate key for each server so that two of them
+ * cannot tell they are talking to the same person. That property is worth
+ * exactly as much here, and would be undone by a single DM key shared across
+ * servers — so the same scope goes into the derivation.
+ *
+ * **The scope, not the address (GRYT-719).** `identityScopeFor` gives the
+ * server's lineage id, and only falls back to the address for a server that
+ * proved nothing. Deriving from the address instead would give a server on a
+ * LAN address and a tunnel two DM keys, and would change the key whenever a
+ * port is taken or a lease moves. For the identity key that bug meant arriving
+ * as a stranger, which GRYT-257 fixed and which is at least visible. Here it
+ * would mean every message ever encrypted to the old key is unreadable, with
+ * nothing logged. `IdentityScope` is branded so the wrong string does not
+ * typecheck.
+ *
+ * The consequence is that a conversation is bound to the server it happens on,
+ * which is what `useDirectMessages.ts` and `conversations.ts` already say about
+ * DMs in plaintext. Encryption does not change the shape, it enforces it.
+ *
+ * ## What this file does not do
+ *
+ * It derives a keypair and computes a shared secret. It does not publish the
+ * public key, does not encrypt a message, and does not know what a conversation
+ * is. Wrapping a per-message key for each member, and the certificate that says
+ * whose public key is whose, are the parts that follow — and the certificate is
+ * the one that decides whether any of this is worth anything, because a shared
+ * secret with a key the server chose for you protects nothing.
+ */
+import { x25519 } from "@noble/curves/ed25519.js";
+import { hkdf } from "@noble/hashes/hkdf.js";
+import { sha256 } from "@noble/hashes/sha2.js";
+/**
+ * Domain separator, and why it is not the identity one.
+ *
+ * `identity-seed.ts` uses `gryt-identity-v1`. Deriving both keys from one seed
+ * under the same label would hand the same 32 bytes to two different
+ * algorithms, which is the kind of reuse that turns two safe primitives into
+ * one unsafe system. A different label makes the two keys independent: knowing
+ * either tells you nothing about the other, because HKDF's outputs for
+ * different `info` are unrelated to anyone without the seed.
+ *
+ * Versioned for the same reason the identity one is. Changing this string
+ * changes every DM key that has ever existed, which would make every message
+ * already sent unreadable — so a `v2` arrives with a migration or not at all.
+ */
+const DERIVATION_SALT = "gryt-dm-v1";
+/**
+ * Exactly 32, and this is where X25519 differs from the P-256 path next door.
+ *
+ * `deriveLocalKeyPair` takes 48 bytes and reduces them modulo the curve order,
+ * because a P-256 scalar has to land in a range that 32 uniform bytes overshoot
+ * slightly, and the excess makes low values fractionally likelier.
+ *
+ * X25519 has no such range. Any 32 bytes is a valid secret — the algorithm
+ * clamps the bits it cares about itself, which is part of its definition rather
+ * than something a caller does. So taking more than 32 and reducing would be
+ * ceremony that copies the shape of the other function without its reason.
+ */
+const SECRET_BYTES = 32;
+function utf8(value) {
+    return new TextEncoder().encode(value);
+}
+/**
+ * Refuse a seed this obviously cannot be right.
+ *
+ * The mirror of `assertUsableSeed` in `identity-seed.ts`, and here for the same
+ * reason: a stub or a platform handing back a constant would give every device
+ * the same DM key, and every user would be able to read every conversation. A
+ * real seed being all one byte has a probability around 2^-248, so nothing
+ * legitimate is being turned away.
+ */
+function assertUsableSeed(seed) {
+    if (seed.length !== SECRET_BYTES) {
+        throw new Error(`A seed is ${SECRET_BYTES} bytes, not ${seed.length}.`);
+    }
+    if (seed.every((byte) => byte === seed[0])) {
+        throw new Error("That seed is a single repeated byte, which is not a seed.");
+    }
+}
+/**
+ * The DM keypair this seed gives for one server.
+ *
+ * Deterministic: the same seed and scope give the same keypair on any device,
+ * which is what makes the recovery phrase enough to read old conversations
+ * again — and, because the scope outlives an address change, what makes them
+ * still readable after the server moves.
+ *
+ * Raw bytes rather than a `CryptoKey`, because WebCrypto's X25519 support is
+ * younger than the browsers Gryt runs on and the agreement below is done by the
+ * curve library anyway. There is nothing to gain from importing a key into an
+ * API that is not going to perform the operation.
+ */
+export function deriveDmKeyPair(seed, scope) {
+    assertUsableSeed(seed);
+    const privateKey = hkdf(sha256, seed, utf8(DERIVATION_SALT), utf8(scope), SECRET_BYTES);
+    return { privateKey, publicKey: x25519.getPublicKey(privateKey) };
+}
+/** The public half alone, for the cases that should not touch the private one. */
+export function dmPublicKey(seed, scope) {
+    return deriveDmKeyPair(seed, scope).publicKey;
+}
+/**
+ * The secret two people share, from one private half and one public half.
+ *
+ * Run through HKDF rather than used raw. The X25519 output is a curve point's
+ * x-coordinate, which is not uniformly distributed over 32 bytes, and a key
+ * derivation function is what turns it into something safe to use as one. The
+ * conversation id goes in as `info`, so the same pair of people talking in two
+ * conversations do not derive the same key in both.
+ *
+ * **This is not enough on its own, and the gap is not in the maths.** Agreement
+ * with the wrong public key succeeds exactly as well as agreement with the right
+ * one — both produce a perfectly good secret. Whether `theirPublicKey` belongs
+ * to the person named beside it is the question the certificate answers, and
+ * until that exists a caller is trusting the server for it.
+ */
+export function dmSharedSecret(privateKey, theirPublicKey, conversationId) {
+    const shared = x25519.getSharedSecret(privateKey, theirPublicKey);
+    return hkdf(sha256, shared, utf8(`${DERIVATION_SALT}-shared`), utf8(conversationId), SECRET_BYTES);
+}