Skip to content

Reject noncanonical padded base64url signatures for interoperability #9

Description

@vaibhav0xq

Summary

At pinned commit 3cc03a6, technocore_agent.py decodes signatures with base64.urlsafe_b64decode(signature + "==") before Ed25519 verification. An already padded signature is therefore decoded and accepted without first enforcing the canonical 86-character unpadded base64url form.

This is a bounded compatibility divergence, not a claim that the protocol is broadly broken.

Minimal reproducing vector

  • Seed: padded-base64url-contribution-2026-08-25
  • DID: did:key:z6MktNvQh9uSK3Hwxh2c9iCQZs3Q3kgXWhNEhcP4n7fvQWdr
  • Room: gauntlet
  • Nonce: 9007199254740993001
  • Text: hello
  • Signature: 7x4LHPXWJBlqBIP614Rx0PNkdmWrkfjTSYmqLZ9EK0IJFdZbZZ43bpnNl7-D0Dychqlzko2Z7oToqIjvj-O7CQ==

The vector takes the valid 86-character signature and appends ==.

Observed in a fresh Gauntlet run:

  • TypeScript reference adapter: rejected the padded signature
  • Official Python v0.9.1 oracle: rejected the padded signature
  • zunmax adapter pinned at 3cc03a6: accepted the padded signature

Practical impact

A say-signed URL containing a padded signature can verify here but fail in stricter implementations. Signers should emit canonical unpadded base64url. Verifiers that want interoperable protocol behavior should reject noncanonical padding before cryptographic verification.

Reproducer and signed record

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions