Ed25519 Public Key
Every VerixID record is cryptographically signed using the Ed25519 algorithm. Anyone — developers, auditors, AI systems, or third-party verifiers — can independently validate signature authenticity using the public key below, with zero reliance on VerixID infrastructure.
VerixID Public Key
The VerixID Ed25519 public key is publicly accessible via the standardized
.well-known directory. Adhering to RFC 8615 conventions for well-known URIs,
this endpoint allows any automated system to fetch the public key without authentication.
Available at: https://verixid.com/.well-known/verixid-public-key.pem
Key Specifications
- Algorithm
- Ed25519 (Edwards-curve Digital Signature Algorithm)
- Distribution Format
- PEM (PKCS#8), accessible at
/.well-known/verixid-public-key.pem - Primary Function
- Signing record state payloads on submission — signature is persisted to ledger
- Private Key Security
- Isolated in secure key management — never exposed to client or browser environments
How to Self-Verify
Verification can be performed fully client-side without relying on VerixID runtime servers — requiring only the public key, the ledger record parameters, and standard cryptographic tools.
Requirements:
1. VerixID Public Key — fetched from /.well-known/verixid-public-key.pem.
2. Ledger record fields: record_id, hash1, server_timestamp, and ownership_key_hash.
3. The ed25519_signature associated with the record ledger entry.
Canonical Canonical Signed Payload
Signatures are computed over a strict, deterministic JSON object sorted alphabetically by key:
{
"hash1": "<sha256_hex>",
"ownership_key_hash": "<sha256_hex>",
"record_id": "<vxYYYYMMxxxxxxxx>",
"server_timestamp": "<ISO8601_UTC>"
}
Sorted Lexicographical Keys
1. hash1 — File cryptographic hash
2. ownership_key_hash — Hashed owner key commitment
3. record_id — Unique record identifier
4. server_timestamp — Immutable registration timestamp
What Ed25519 Proves
It is critical to understand precisely what an Ed25519 cryptographic signature guarantees — and what falls outside its scope.
Guaranteed Proofs ✅
- Record Authenticity
- Confirms that the record was definitively issued by VerixID's system authority.
- Data Integrity
- Validates that no record fields have been altered since initial ledger commitment.
- Tamper Evidence
- Any alteration — down to a single byte or character — renders the signature invalid.
Mathematical Proof Model:
· SHA-256: "Has this underlying asset changed?"
· Ed25519: "Was this record genuinely published by VerixID?"
· Timestamp: "When was this entry committed to the ledger?"
Out of Scope ❌
- Personal Identity
- VerixID does not track submitter identities — the system is strictly privacy-first and structurally anonymous.
- File Payload
- The signature attests only to the hash registration, not the contents of the underlying file.
- Intellectual Property / Copyright
- Legal ownership attribution falls outside the direct scope of the mathematical protocol.
Triple-Layer Proof Architecture
VerixID relies on three mutually reinforcing layers of mathematical verification, eliminating single points of trust failure.
SHA-256 Digest
Local client-side fingerprinting. Computed entirely in-browser — files never leave your device.
Ed25519 Signature
Ensures structural authenticity and guarantees zero post-registration tampering.
Immutable Ledger
Append-only log architecture with precision timestamping and defined 1-year retention rules.
Together, these components establish a trustless verification framework. Validation depends on mathematical properties that anyone can independently audit at any time using open tools.
"We don't take sides. Math does."
This documentation outlines the practical realization of that ethos: even VerixID cannot fabricate a backdated or altered record without invalidating the cryptographic signature.
Technical FAQ
- Ed25519 offers smaller key sizes, faster signature generation, and superior security resilience. It is natively supported by modern Web Crypto APIs without external third-party dependencies.
-
Every record references a specific
key_version. Following a key rotation, legacy public keys remain archived in the/.well-known/directory with explicit version tagging to ensure historical records remain perpetually verifiable. - No. Scheduled key rotations are documented in our changelog and announced in advance. Key lifecycle procedures are strictly controlled and deterministic.
- The private signing key is stored exclusively as an encrypted environment secret at rest. It is never exposed to client runtime code, source repositories, or web browsers.
- Yes. Once the public key and raw record payload are retrieved, verification can be executed entirely offline using standard cryptographic tools in any language environment.