/**
 * The one HMAC used across peer sharing.
 *
 * Leases, receipts and coin notes all need the same thing: a statement one node
 * makes that another can check without being able to forge. They had grown
 * separate copies of the same twenty lines, which is how two of them end up with
 * different canonicalisation and a signature that verifies on one path and not
 * the other.
 *
 * **Why HMAC and not a signature scheme.** The key-distribution problem that
 * asymmetric keys solve does not exist here: every one of these statements
 * passes between exactly two nodes that already share a secret. The package's
 * browser bundle also stubs `node:crypto` down to a subset with no Ed25519 in
 * it, and these modules are reachable from that build.
 *
 * **What that costs.** A MAC proves authorship only to someone holding the key,
 * so a receipt is evidence between the two parties to it and not to a third.
 * Coin notes are built around that limit rather than against it — see
 * `shareNotes.ts`.
 *
 * @module proxy/shareSigning
 */
/** A secret suitable for keying any of the statements in this subsystem. */
export declare function generateShareSecret(): string;
/**
 * Canonicalise and sign.
 *
 * The payload is serialized with its keys sorted, so two nodes that built the
 * same object in a different order still agree on the bytes being signed.
 */
export declare function signSharePayload(payload: unknown, secret: string): string;
/** Does `signature` match what this secret would produce for this payload? */
export declare function verifySharePayload(payload: unknown, signature: string, secret: string): boolean;
/**
 * Compare two strings without leaking where they diverge.
 *
 * Hand-rolled rather than `crypto.timingSafeEqual` because that is one of the
 * things the browser bundle's `node:crypto` stub does not carry.
 */
export declare function secretsMatch(expected: string, presented: string): boolean;