@cello-protocol/crypto 0.0.58 → 0.0.60

package/dist/session-salt.d.ts

@@ -0,0 +1,129 @@
+/**
+ * THE SESSION SALT — Decisions Carried #8, #9, #10 (Andre, 2026-08-23).
+ *
+ * ⚠️ AGREED, STORED, AND VERIFIABLE — BUT NO SENDER SALTS YET. Two revisions of this header have
+ * now been overtaken, so it states the boundary precisely rather than a slogan:
+ *
+ *   `session-salt-agreement.ts` calls `deriveSessionSalt` and `saltFingerprint`; `content_salt` has
+ *   a writer and a reader; and `wire-content-hash.ts` DOES import `saltedContentHash` — the RECEIVE
+ *   path will verify a frame that names `hmac-sha256-salt-v1` (`DOD-M15-SEALWIRE-1` part B1).
+ *
+ *   What no code in this build does is SEND one. Every send site still calls `wireContentHash`, so
+ *   no message's hash depends on a salt yet, and part B2 is what flips that.
+ *
+ * The distinction matters to anyone auditing reachability: the salted path is live inbound and dead
+ * outbound. A reader who takes "nothing hashes with it" from an older revision of this header would
+ * wrongly conclude the salted branch cannot execute in production at all.
+ *
+ * ─── Why this is a separate file from the key agreement ────────────────────────────────────────
+ *
+ * It used to be a second output of `deriveSessionSecrets`, and that was the defect. The envelope key
+ * and the salt are unrelated goals that merely both need a shared secret:
+ *
+ *   the **envelope key** stops the relay reading messages in flight, and MUST be destroyed at close;
+ *   the **session salt** stops anyone holding stored hashes from confirming a guessed message, and
+ *   MUST survive for the life of the session.
+ *
+ * **Deriving both from one secret tied "must be forgotten" to "must be kept forever."** Every
+ * consequence that flowed from it — salt epochs, per-leaf epoch attribution, lockstep switching —
+ * was a symptom of that coupling, not a real requirement. Keeping the MOMENT (one exchange) and
+ * dropping the DERIVATION removes all of them.
+ *
+ * ─── What it defends against, and it is live today ─────────────────────────────────────────────
+ *
+ * `wireContentHash` is `SHA-256(0x00 ‖ content)` with nothing session-specific in it. So the same
+ * message text is the same 32 bytes in **every conversation, between every pair of agents, forever**
+ * — a relay can correlate one message across sessions and agent pairs, and can build a table of
+ * common short messages once and read it everywhere (`DOD-M15-HASHCORRELATE-1`).
+ *
+ * Chaining would not fix it: the adversary holds the previous hash, so they would compute
+ * `hash(previous ‖ guess)`. Chaining hides repeats; it does not hide content. A secret per-session
+ * salt does.
+ *
+ * ─── BOTH SIDES CONTRIBUTE, and why that is a requirement rather than a nicety ─────────────────
+ *
+ * Not initiator-minted. The client is open source and an operator can modify their own build, so a
+ * single minter could unilaterally destroy the property **for both parties** — always send the same
+ * salt, or a low-entropy one — and every conversation that client has becomes guessable by any relay
+ * holding the hashes. The honest peer cannot detect it and never consented to it.
+ *
+ * Both-contribute means **one honest participant is enough**: if either side's contribution is
+ * unpredictable, the salt is. Each side can also verify its own contribution was actually used.
+ * Same principle as the sovereign-node rule — no single party can unilaterally break a guarantee.
+ *
+ * (The envelope key already has this property structurally: X25519 ephemeral-ephemeral combines both
+ * secrets, and `session-key-agreement.ts` refuses the small-order point that is the one way a peer
+ * could force a degenerate result. Same guarantee, different mechanism.)
+ *
+ * ─── 🚨 THE SECRECY HERE IS THE CHANNEL'S, NOT THE CONSTRUCTION'S ──────────────────────────────
+ *
+ * The single most important thing about this module, and it does NOT resemble the envelope key.
+ *
+ * The key is a DH secret: a passive relay holding both public keys cannot compute it, and
+ * `dod-m15-keyagree-1.test.ts` pins exactly that. **The salt is a function of two values that are
+ * SENT.** Anyone who can read both contributions derives it with the same public HKDF label. There
+ * is no "a third party cannot derive it" test in this module, and there cannot be one.
+ *
+ * So "one honest participant is enough" carries a precondition that must never be dropped:
+ * unpredictable **to anyone who cannot read the exchange**.
+ *
+ * ─── THEREFORE, a rule for `DOD-M15-SEALWIRE-1`, which owns the wire ──────────────────────────
+ *
+ *   The contributions MUST be exchanged on the peer-to-peer `/cello/content/1.0.0` stream. It rides
+ *   circuit-relay-v2 carrying its own Noise session, so a relay forwarding it sees ciphertext.
+ *
+ *   They MUST NEVER appear in `session_offer` / `session_offer_accept`, or anything else a
+ *   DIRECTORY brokers. **That is the trap:** today the ONLY round trip at session open runs on the
+ *   directory's signaling stream (`session-ceremony.ts`), so it is the natural, obvious place to put
+ *   a contribution — one round trip, at open, before any leaf — and it is precisely the channel
+ *   Decision #8 forbids. Nothing about this function protects the salt if that rule is broken, and
+ *   a session that shipped that way cannot be repaired afterwards: the relay already holds the salt
+ *   and the hashes.
+ *
+ * Residual, and it now covers TWO values rather than one: the contributions are unauthenticated,
+ * exactly like the ephemerals, so an ACTIVE on-path attacker who substitutes both sides defeats the
+ * salt as well as the key. That is `DOD-M15-EPHEMERAL-AUTH-1`.
+ */
+/** Contributions and the salt are all 32 bytes. */
+export declare const SALT_CONTRIBUTION_BYTES = 32;
+export declare const SESSION_SALT_BYTES = 32;
+/** Enough to detect a disagreement; short enough to be obviously not the salt. */
+export declare const SALT_FINGERPRINT_BYTES = 8;
+/** This side's random contribution. Fresh per session; sent to the peer. */
+export declare function generateSaltContribution(): Uint8Array;
+/**
+ * Combine the two contributions into the session salt.
+ *
+ * CANONICAL ORDER (lexicographic), so both sides compute identical bytes without agreeing on who
+ * initiated. The two daemons reach this from different code paths; ordering by role would mean a
+ * disagreement about "who started it" produced two different salts — and a salt disagreement is the
+ * least debuggable failure in this system, because the send succeeds and the receiver discards.
+ */
+export declare function deriveSessionSalt(ourContribution: Uint8Array, peerContribution: Uint8Array): Uint8Array;
+/**
+ * A short, one-way fingerprint of the salt, for the agreement check at session open — Decision #10.
+ *
+ * **The salt itself is never compared on the wire.** A fingerprint is derived under its own HKDF
+ * label, so it cannot be worked back to the salt, and it is deliberately short so nobody mistakes it
+ * for key material.
+ *
+ * Why compare at all: a salt disagreement makes every message fail the receive-path authenticity
+ * check, and `wire-content-hash.ts`'s own header calls that the least debuggable shape there is —
+ * the send succeeds, `parked: false`, the sender's log says the frame left, and the receiver discards
+ * before anything is logged about it. It cost two real daemons to find once. Refusing the session at
+ * open, with a named reason, is the difference between a diagnosis and a week.
+ */
+export declare function saltFingerprint(salt: Uint8Array): Uint8Array;
+/**
+ * The salted content hash — Decision #9.
+ *
+ * **HMAC, not `SHA-256(salt ‖ content)`.** The naive concatenation is vulnerable to length
+ * extension: an attacker who holds `H(salt ‖ m)` and knows `|salt|` can compute `H(salt ‖ m ‖ pad ‖
+ * m')` without knowing the salt. HMAC is the standard construction for exactly this and costs
+ * nothing extra here.
+ *
+ * The `0x00` domain byte is retained inside the message so this stays domain-separated from any
+ * other HMAC over the same key, and so the unsalted and salted forms can never collide.
+ */
+export declare function saltedContentHash(salt: Uint8Array, content: Uint8Array): Uint8Array;
+//# sourceMappingURL=session-salt.d.ts.map

package/dist/session-salt.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"session-salt.d.ts","sourceRoot":"","sources":["../src/session-salt.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqFG;AAOH,mDAAmD;AACnD,eAAO,MAAM,uBAAuB,KAAK,CAAC;AAC1C,eAAO,MAAM,kBAAkB,KAAK,CAAC;AACrC,kFAAkF;AAClF,eAAO,MAAM,sBAAsB,IAAI,CAAC;AAMxC,4EAA4E;AAC5E,wBAAgB,wBAAwB,IAAI,UAAU,CAErD;AAQD;;;;;;;GAOG;AACH,wBAAgB,iBAAiB,CAAC,eAAe,EAAE,UAAU,EAAE,gBAAgB,EAAE,UAAU,GAAG,UAAU,CAkEvG;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,eAAe,CAAC,IAAI,EAAE,UAAU,GAAG,UAAU,CAE5D;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,iBAAiB,CAAC,IAAI,EAAE,UAAU,EAAE,OAAO,EAAE,UAAU,GAAG,UAAU,CAKnF"}

package/dist/session-salt.js

@@ -0,0 +1,205 @@
+/**
+ * THE SESSION SALT — Decisions Carried #8, #9, #10 (Andre, 2026-08-23).
+ *
+ * ⚠️ AGREED, STORED, AND VERIFIABLE — BUT NO SENDER SALTS YET. Two revisions of this header have
+ * now been overtaken, so it states the boundary precisely rather than a slogan:
+ *
+ *   `session-salt-agreement.ts` calls `deriveSessionSalt` and `saltFingerprint`; `content_salt` has
+ *   a writer and a reader; and `wire-content-hash.ts` DOES import `saltedContentHash` — the RECEIVE
+ *   path will verify a frame that names `hmac-sha256-salt-v1` (`DOD-M15-SEALWIRE-1` part B1).
+ *
+ *   What no code in this build does is SEND one. Every send site still calls `wireContentHash`, so
+ *   no message's hash depends on a salt yet, and part B2 is what flips that.
+ *
+ * The distinction matters to anyone auditing reachability: the salted path is live inbound and dead
+ * outbound. A reader who takes "nothing hashes with it" from an older revision of this header would
+ * wrongly conclude the salted branch cannot execute in production at all.
+ *
+ * ─── Why this is a separate file from the key agreement ────────────────────────────────────────
+ *
+ * It used to be a second output of `deriveSessionSecrets`, and that was the defect. The envelope key
+ * and the salt are unrelated goals that merely both need a shared secret:
+ *
+ *   the **envelope key** stops the relay reading messages in flight, and MUST be destroyed at close;
+ *   the **session salt** stops anyone holding stored hashes from confirming a guessed message, and
+ *   MUST survive for the life of the session.
+ *
+ * **Deriving both from one secret tied "must be forgotten" to "must be kept forever."** Every
+ * consequence that flowed from it — salt epochs, per-leaf epoch attribution, lockstep switching —
+ * was a symptom of that coupling, not a real requirement. Keeping the MOMENT (one exchange) and
+ * dropping the DERIVATION removes all of them.
+ *
+ * ─── What it defends against, and it is live today ─────────────────────────────────────────────
+ *
+ * `wireContentHash` is `SHA-256(0x00 ‖ content)` with nothing session-specific in it. So the same
+ * message text is the same 32 bytes in **every conversation, between every pair of agents, forever**
+ * — a relay can correlate one message across sessions and agent pairs, and can build a table of
+ * common short messages once and read it everywhere (`DOD-M15-HASHCORRELATE-1`).
+ *
+ * Chaining would not fix it: the adversary holds the previous hash, so they would compute
+ * `hash(previous ‖ guess)`. Chaining hides repeats; it does not hide content. A secret per-session
+ * salt does.
+ *
+ * ─── BOTH SIDES CONTRIBUTE, and why that is a requirement rather than a nicety ─────────────────
+ *
+ * Not initiator-minted. The client is open source and an operator can modify their own build, so a
+ * single minter could unilaterally destroy the property **for both parties** — always send the same
+ * salt, or a low-entropy one — and every conversation that client has becomes guessable by any relay
+ * holding the hashes. The honest peer cannot detect it and never consented to it.
+ *
+ * Both-contribute means **one honest participant is enough**: if either side's contribution is
+ * unpredictable, the salt is. Each side can also verify its own contribution was actually used.
+ * Same principle as the sovereign-node rule — no single party can unilaterally break a guarantee.
+ *
+ * (The envelope key already has this property structurally: X25519 ephemeral-ephemeral combines both
+ * secrets, and `session-key-agreement.ts` refuses the small-order point that is the one way a peer
+ * could force a degenerate result. Same guarantee, different mechanism.)
+ *
+ * ─── 🚨 THE SECRECY HERE IS THE CHANNEL'S, NOT THE CONSTRUCTION'S ──────────────────────────────
+ *
+ * The single most important thing about this module, and it does NOT resemble the envelope key.
+ *
+ * The key is a DH secret: a passive relay holding both public keys cannot compute it, and
+ * `dod-m15-keyagree-1.test.ts` pins exactly that. **The salt is a function of two values that are
+ * SENT.** Anyone who can read both contributions derives it with the same public HKDF label. There
+ * is no "a third party cannot derive it" test in this module, and there cannot be one.
+ *
+ * So "one honest participant is enough" carries a precondition that must never be dropped:
+ * unpredictable **to anyone who cannot read the exchange**.
+ *
+ * ─── THEREFORE, a rule for `DOD-M15-SEALWIRE-1`, which owns the wire ──────────────────────────
+ *
+ *   The contributions MUST be exchanged on the peer-to-peer `/cello/content/1.0.0` stream. It rides
+ *   circuit-relay-v2 carrying its own Noise session, so a relay forwarding it sees ciphertext.
+ *
+ *   They MUST NEVER appear in `session_offer` / `session_offer_accept`, or anything else a
+ *   DIRECTORY brokers. **That is the trap:** today the ONLY round trip at session open runs on the
+ *   directory's signaling stream (`session-ceremony.ts`), so it is the natural, obvious place to put
+ *   a contribution — one round trip, at open, before any leaf — and it is precisely the channel
+ *   Decision #8 forbids. Nothing about this function protects the salt if that rule is broken, and
+ *   a session that shipped that way cannot be repaired afterwards: the relay already holds the salt
+ *   and the hashes.
+ *
+ * Residual, and it now covers TWO values rather than one: the contributions are unauthenticated,
+ * exactly like the ephemerals, so an ACTIVE on-path attacker who substitutes both sides defeats the
+ * salt as well as the key. That is `DOD-M15-EPHEMERAL-AUTH-1`.
+ */
+import { hkdf } from "@noble/hashes/hkdf.js";
+import { sha256 } from "@noble/hashes/sha2.js";
+import { hmac } from "@noble/hashes/hmac.js";
+import { randomBytes } from "node:crypto";
+/** Contributions and the salt are all 32 bytes. */
+export const SALT_CONTRIBUTION_BYTES = 32;
+export const SESSION_SALT_BYTES = 32;
+/** Enough to detect a disagreement; short enough to be obviously not the salt. */
+export const SALT_FINGERPRINT_BYTES = 8;
+const ENC = new TextEncoder();
+const INFO_SESSION_SALT = ENC.encode("cello/session/v1/salt");
+const INFO_SALT_FINGERPRINT = ENC.encode("cello/session/v1/salt-fingerprint");
+/** This side's random contribution. Fresh per session; sent to the peer. */
+export function generateSaltContribution() {
+    return new Uint8Array(randomBytes(SALT_CONTRIBUTION_BYTES));
+}
+function isAllZero(b) {
+    let acc = 0;
+    for (const x of b)
+        acc |= x;
+    return acc === 0;
+}
+/**
+ * Combine the two contributions into the session salt.
+ *
+ * CANONICAL ORDER (lexicographic), so both sides compute identical bytes without agreeing on who
+ * initiated. The two daemons reach this from different code paths; ordering by role would mean a
+ * disagreement about "who started it" produced two different salts — and a salt disagreement is the
+ * least debuggable failure in this system, because the send succeeds and the receiver discards.
+ */
+export function deriveSessionSalt(ourContribution, peerContribution) {
+    /**
+     * REFUSE A DEGENERATE PEER CONTRIBUTION — the same posture the key agreement takes toward a
+     * small-order point, and for the same reason: a peer that contributes nothing has unilaterally
+     * decided the salt, which is exactly the property both-contribute exists to prevent.
+     */
+    if (peerContribution.length !== SALT_CONTRIBUTION_BYTES) {
+        throw new Error(`SESSION SALT: the peer's salt contribution must be ${SALT_CONTRIBUTION_BYTES} bytes, got ` +
+            `${peerContribution.length}. Refusing rather than padding — a short contribution silently ` +
+            "zero-extended is a salt this side did not really help choose.");
+    }
+    if (isAllZero(peerContribution)) {
+        throw new Error("SESSION SALT: the peer's salt contribution is all zeros, which means it contributed nothing " +
+            "and the salt would be decided by one side alone. That is the property both-contribute exists " +
+            "to prevent: a modified client could then make every one of its conversations guessable by any " +
+            "relay holding the hashes, without its peer being able to tell. Refusing.");
+    }
+    if (ourContribution.length !== SALT_CONTRIBUTION_BYTES) {
+        throw new Error(`SESSION SALT: our own salt contribution must be ${SALT_CONTRIBUTION_BYTES} bytes, got ` +
+            `${ourContribution.length}. This is a local defect, not something the peer did.`);
+    }
+    /**
+     * OUR OWN all-zero contribution is refused too — review F6, and the asymmetry mattered.
+     *
+     * Without this, a daemon with a broken or patched RNG derives happily while the PEER refuses with
+     * *"the peer's salt contribution is all zeros"* — so the operator whose machine is actually broken
+     * reads a failure that blames their counterparty. `session-key-agreement.ts` already established
+     * the symmetric pattern for lengths ("this is a local defect, not something the peer did"); this
+     * file had it for length and not for zero.
+     */
+    if (isAllZero(ourContribution)) {
+        throw new Error("SESSION SALT: our OWN salt contribution is all zeros, so this side contributed nothing. This " +
+            "is a LOCAL defect — a broken or patched random source — not something the peer did. Refusing " +
+            "rather than deriving a salt one side chose alone.");
+    }
+    /**
+     * A REFLECTED contribution — the peer echoing ours back — is refused, matching
+     * `session-key-agreement.ts`'s reflection check. Confidentiality survives (our half is random), so
+     * this is hygiene rather than a break; but the module claims each side can verify its contribution
+     * was used, and nothing was verifying the PEER contributed at all.
+     */
+    if (Buffer.compare(Buffer.from(ourContribution), Buffer.from(peerContribution)) === 0) {
+        throw new Error("SESSION SALT: the peer's salt contribution is identical to our own — the peer contributed " +
+            "nothing to the agreement. Refusing: this is a reflection, not an exchange.");
+    }
+    const [first, second] = Buffer.compare(Buffer.from(ourContribution), Buffer.from(peerContribution)) < 0
+        ? [ourContribution, peerContribution]
+        : [peerContribution, ourContribution];
+    const ikm = new Uint8Array(first.length + second.length);
+    ikm.set(first, 0);
+    ikm.set(second, first.length);
+    // No salt argument to HKDF here: the session id is not needed to separate sessions, because the
+    // contributions are fresh random per session and already do it.
+    return hkdf(sha256, ikm, new Uint8Array(0), INFO_SESSION_SALT, SESSION_SALT_BYTES);
+}
+/**
+ * A short, one-way fingerprint of the salt, for the agreement check at session open — Decision #10.
+ *
+ * **The salt itself is never compared on the wire.** A fingerprint is derived under its own HKDF
+ * label, so it cannot be worked back to the salt, and it is deliberately short so nobody mistakes it
+ * for key material.
+ *
+ * Why compare at all: a salt disagreement makes every message fail the receive-path authenticity
+ * check, and `wire-content-hash.ts`'s own header calls that the least debuggable shape there is —
+ * the send succeeds, `parked: false`, the sender's log says the frame left, and the receiver discards
+ * before anything is logged about it. It cost two real daemons to find once. Refusing the session at
+ * open, with a named reason, is the difference between a diagnosis and a week.
+ */
+export function saltFingerprint(salt) {
+    return hkdf(sha256, salt, new Uint8Array(0), INFO_SALT_FINGERPRINT, SALT_FINGERPRINT_BYTES);
+}
+/**
+ * The salted content hash — Decision #9.
+ *
+ * **HMAC, not `SHA-256(salt ‖ content)`.** The naive concatenation is vulnerable to length
+ * extension: an attacker who holds `H(salt ‖ m)` and knows `|salt|` can compute `H(salt ‖ m ‖ pad ‖
+ * m')` without knowing the salt. HMAC is the standard construction for exactly this and costs
+ * nothing extra here.
+ *
+ * The `0x00` domain byte is retained inside the message so this stays domain-separated from any
+ * other HMAC over the same key, and so the unsalted and salted forms can never collide.
+ */
+export function saltedContentHash(salt, content) {
+    const msg = new Uint8Array(1 + content.length);
+    msg[0] = 0x00;
+    msg.set(content, 1);
+    return hmac(sha256, salt, msg);
+}
+//# sourceMappingURL=session-salt.js.map

package/dist/session-salt.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"session-salt.js","sourceRoot":"","sources":["../src/session-salt.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqFG;AAEH,OAAO,EAAE,IAAI,EAAE,MAAM,uBAAuB,CAAC;AAC7C,OAAO,EAAE,MAAM,EAAE,MAAM,uBAAuB,CAAC;AAC/C,OAAO,EAAE,IAAI,EAAE,MAAM,uBAAuB,CAAC;AAC7C,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AAE1C,mDAAmD;AACnD,MAAM,CAAC,MAAM,uBAAuB,GAAG,EAAE,CAAC;AAC1C,MAAM,CAAC,MAAM,kBAAkB,GAAG,EAAE,CAAC;AACrC,kFAAkF;AAClF,MAAM,CAAC,MAAM,sBAAsB,GAAG,CAAC,CAAC;AAExC,MAAM,GAAG,GAAG,IAAI,WAAW,EAAE,CAAC;AAC9B,MAAM,iBAAiB,GAAG,GAAG,CAAC,MAAM,CAAC,uBAAuB,CAAC,CAAC;AAC9D,MAAM,qBAAqB,GAAG,GAAG,CAAC,MAAM,CAAC,mCAAmC,CAAC,CAAC;AAE9E,4EAA4E;AAC5E,MAAM,UAAU,wBAAwB;IACtC,OAAO,IAAI,UAAU,CAAC,WAAW,CAAC,uBAAuB,CAAC,CAAC,CAAC;AAC9D,CAAC;AAED,SAAS,SAAS,CAAC,CAAa;IAC9B,IAAI,GAAG,GAAG,CAAC,CAAC;IACZ,KAAK,MAAM,CAAC,IAAI,CAAC;QAAE,GAAG,IAAI,CAAC,CAAC;IAC5B,OAAO,GAAG,KAAK,CAAC,CAAC;AACnB,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,iBAAiB,CAAC,eAA2B,EAAE,gBAA4B;IACzF;;;;OAIG;IACH,IAAI,gBAAgB,CAAC,MAAM,KAAK,uBAAuB,EAAE,CAAC;QACxD,MAAM,IAAI,KAAK,CACb,sDAAsD,uBAAuB,cAAc;YAC3F,GAAG,gBAAgB,CAAC,MAAM,iEAAiE;YAC3F,+DAA+D,CAChE,CAAC;IACJ,CAAC;IACD,IAAI,SAAS,CAAC,gBAAgB,CAAC,EAAE,CAAC;QAChC,MAAM,IAAI,KAAK,CACb,8FAA8F;YAC9F,+FAA+F;YAC/F,gGAAgG;YAChG,0EAA0E,CAC3E,CAAC;IACJ,CAAC;IACD,IAAI,eAAe,CAAC,MAAM,KAAK,uBAAuB,EAAE,CAAC;QACvD,MAAM,IAAI,KAAK,CACb,mDAAmD,uBAAuB,cAAc;YACxF,GAAG,eAAe,CAAC,MAAM,uDAAuD,CACjF,CAAC;IACJ,CAAC;IACD;;;;;;;;OAQG;IACH,IAAI,SAAS,CAAC,eAAe,CAAC,EAAE,CAAC;QAC/B,MAAM,IAAI,KAAK,CACb,+FAA+F;YAC/F,+FAA+F;YAC/F,mDAAmD,CACpD,CAAC;IACJ,CAAC;IACD;;;;;OAKG;IACH,IAAI,MAAM,CAAC,OAAO,CAAC,MAAM,CAAC,IAAI,CAAC,eAAe,CAAC,EAAE,MAAM,CAAC,IAAI,CAAC,gBAAgB,CAAC,CAAC,KAAK,CAAC,EAAE,CAAC;QACtF,MAAM,IAAI,KAAK,CACb,4FAA4F;YAC5F,4EAA4E,CAC7E,CAAC;IACJ,CAAC;IAED,MAAM,CAAC,KAAK,EAAE,MAAM,CAAC,GAAG,MAAM,CAAC,OAAO,CAAC,MAAM,CAAC,IAAI,CAAC,eAAe,CAAC,EAAE,MAAM,CAAC,IAAI,CAAC,gBAAgB,CAAC,CAAC,GAAG,CAAC;QACrG,CAAC,CAAC,CAAC,eAAe,EAAE,gBAAgB,CAAC;QACrC,CAAC,CAAC,CAAC,gBAAgB,EAAE,eAAe,CAAC,CAAC;IAExC,MAAM,GAAG,GAAG,IAAI,UAAU,CAAC,KAAK,CAAC,MAAM,GAAG,MAAM,CAAC,MAAM,CAAC,CAAC;IACzD,GAAG,CAAC,GAAG,CAAC,KAAK,EAAE,CAAC,CAAC,CAAC;IAClB,GAAG,CAAC,GAAG,CAAC,MAAM,EAAE,KAAK,CAAC,MAAM,CAAC,CAAC;IAC9B,gGAAgG;IAChG,gEAAgE;IAChE,OAAO,IAAI,CAAC,MAAM,EAAE,GAAG,EAAE,IAAI,UAAU,CAAC,CAAC,CAAC,EAAE,iBAAiB,EAAE,kBAAkB,CAAC,CAAC;AACrF,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,eAAe,CAAC,IAAgB;IAC9C,OAAO,IAAI,CAAC,MAAM,EAAE,IAAI,EAAE,IAAI,UAAU,CAAC,CAAC,CAAC,EAAE,qBAAqB,EAAE,sBAAsB,CAAC,CAAC;AAC9F,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,iBAAiB,CAAC,IAAgB,EAAE,OAAmB;IACrE,MAAM,GAAG,GAAG,IAAI,UAAU,CAAC,CAAC,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC;IAC/C,GAAG,CAAC,CAAC,CAAC,GAAG,IAAI,CAAC;IACd,GAAG,CAAC,GAAG,CAAC,OAAO,EAAE,CAAC,CAAC,CAAC;IACpB,OAAO,IAAI,CAAC,MAAM,EAAE,IAAI,EAAE,GAAG,CAAC,CAAC;AACjC,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cello-protocol/crypto",
-  "version": "0.0.58",
+  "version": "0.0.60",
   "private": false,
   "type": "module",
   "engines": {