HMAC vs. Asymmetric Signing: Tradeoffs for Asset Provenance

The Question That Drives the Choice

The canonical recommendation for document signing is asymmetric cryptography — RSA or ECDSA. You sign with a private key, anyone can verify with the corresponding public key. No shared secret, no key distribution problem. PGP-signed emails, code signing certificates, TLS — asymmetric cryptography is the standard for public-facing trust systems.

So why does Ledgible v1 use HMAC-SHA256?

The answer comes down to a single question: who is the verifier, and do they need to operate independently of you?

In a system where verification must work without any involvement from the signing party — where anyone in the world should be able to verify a signature using only a public key and the signed content — asymmetric signing is the correct choice. This is sovereign verifiability: the record is self-contained and verifiable even if the signing organization ceases to exist.

In a system where verification routes through an API operated by the same party that signed the content, the key distribution advantage of asymmetric cryptography does not apply. The verifier is not unknown. They are calling an endpoint you control. The cryptographic property that matters is tamper-evidence — proof that the content has not been modified since signing — not public verifiability of a key you have never distributed.

HMAC-SHA256: How It Works in the Ledgible Context

HMAC (Hash-based Message Authentication Code) with SHA-256 produces a fixed-length authentication tag by applying SHA-256 twice over the message and a secret key. The key insight is that the tag can only be produced by someone who holds the secret key. Anyone with the key can verify the tag — but "anyone" in this context means the system, not the public.

In Ledgible, the HMAC is computed over a canonical JSON payload of the provenance record:

function signRecord(record: CanonicalRecord, signingSecret: string): string {
  // Sort keys to ensure deterministic serialization
  const sortedKeys = Object.keys(record).sort();
  const canonical: Record<string, string> = {};
  sortedKeys.forEach(k => { canonical[k] = record[k]; });

  const payload = JSON.stringify(canonical);

  return crypto
    .createHmac('sha256', signingSecret)
    .update(payload)
    .digest('hex');
}

The canonical payload includes asset_id, org_id, canonical_hash, creator_id, tool_id, and signed_at — the fields that define the provenance claim. Keys are sorted before serialization to ensure that two identical records always produce identical signatures regardless of JSON key insertion order.

Asymmetric Signing: When It Is the Right Choice

Asymmetric signing (RSA, ECDSA, Ed25519) produces a signature using a private key that can be verified using the corresponding public key. The private key is secret; the public key can be freely distributed.

This architecture enables sovereign verifiability: the ability to verify a signature using only the public key, the signature, and the signed content — with no dependency on any service, API, or organization. The signed record is self-contained.

This matters in specific scenarios:

Long-term archival provenance

If a content provenance record needs to be verifiable in 20 years — after the signing organization may have changed, been acquired, or ceased to exist — asymmetric signing with published public keys is the only approach that guarantees future verifiability.

Cross-organizational verification without a trusted intermediary

If two organizations need to exchange signed content and verify each other's signatures without routing through a shared service, asymmetric signing enables this. HMAC requires a shared secret, which requires a prior relationship and key exchange.

Offline verification

If verification must work without network access — in air-gapped environments, in field operations, at border inspection points — a self-contained signature verifiable with a published public key is the correct architecture.

Legal evidentiary use

Some jurisdictions and legal frameworks have specific requirements about signature formats for electronic evidence. Asymmetric signatures produced by hardware security modules (HSMs) are more widely accepted in formal legal proceedings than HMAC-based records.

Why We Chose HMAC for v1

The enterprise content provenance use cases Ledgible serves in v1 share a common property: verification routes through the Ledgible API.

A brand safety auditor checking whether a campaign image was AI-generated calls our verify endpoint. A regulatory compliance officer querying the provenance of a published asset calls our verify endpoint. A publishing partner confirming the authenticity of a submitted image calls our verify endpoint. In all of these cases, Ledgible is the verifier. The verifier is not unknown.

Given this, HMAC-SHA256 offers meaningful advantages over asymmetric signing for v1:

• •Operational simplicity: HMAC uses a single secret key per organization. Key management is straightforward: generate a secure random key at org creation, store it encrypted at rest, rotate it on a defined schedule. Asymmetric signing requires key pair generation, certificate management, public key distribution infrastructure, and revocation handling.
• •Performance: HMAC-SHA256 is faster than RSA or ECDSA at signing and verification. At the volumes enterprise pipelines produce — thousands of assets per day — the performance difference is measurable.
• •Auditability: An HMAC-based signing system with a well-designed key management layer is easier to audit than an asymmetric signing system. The key material is centralized; the signing operations are logged; the verification path is straightforward.
• •Migration path is additive: The transition from HMAC to asymmetric signing does not require changing the API schema, the data model, or any caller. Only the signature field value and the signing/verification function change.

The Migration Path to Asymmetric Signing

Ledgible's Phase 2 roadmap includes asymmetric signing for enterprise customers who require sovereign verifiability. The migration is designed to be non-breaking.

The Phase 2 interface accepts a signing key reference and dispatches to the appropriate implementation:

export async function signRecord(
  record: CanonicalRecord,
  signingKey: SigningKey
): Promise<string> {
  switch (signingKey.type) {
    case 'hmac':
      return signWithHMAC(record, signingKey.secret);
    case 'ecdsa-p256':
      return signWithECDSA(record, signingKey.privateKey);
    case 'kms':
      return signWithKMS(record, signingKey.keyArn);
    default:
      throw new Error(`Unsupported signing key type: ${signingKey.type}`);
  }
}

The signature field in provenance records includes a prefix identifying the algorithm: hmac-sha256:..., ecdsa-p256:..., kms-rsa-2048:.... Verification routes to the appropriate verification function based on the prefix. Records signed with HMAC continue to verify correctly after the migration; new records can use asymmetric signing.

How This Compares to Blockchain-Based Signing

For enterprise content pipelines that need to sign thousands of assets per day, the latency and cost profile of blockchain signing is prohibitive at current chain throughput levels. Ledgible treats blockchain anchoring as an optional supplemental layer — an anchor receipt that can be added to a provenance record for customers who need the sovereign verifiability guarantee — not as the signing mechanism itself.

What This Means for Your Integration

If you are integrating with Ledgible today, you are using HMAC-SHA256 signing. This is appropriate for:

• •Compliance with EU AI Act Article 50 and equivalent frameworks
• •Brand safety and content authenticity audits
• •Internal chain-of-custody tracking
• •Legal dispute documentation where Ledgible can provide verification as a third party

If your use case requires sovereign verifiability — verification that works without any Ledgible involvement, or long-term archival provenance that must outlast any single service — reach out to discuss the Phase 2 asymmetric signing roadmap. We are building this explicitly for regulated industries (financial services, pharmaceutical, government) where long-term verifiability is a compliance requirement.

The signing algorithm is an implementation detail. The provenance record it produces — and the audit trail it creates — is what matters for your use case.