Vectis

Vectis is an open-source advanced data protection toolkit.

Sensitive input in. Protected representation out.

Vectis protects and transforms sensitive values through a consistent HTTP API and CLI. Operator-signed profiles define the allowed operations, algorithms, keys, permissions, and lifecycle policy.

Vectis has one job: protecting sensitive data objects. It composes with identity, TLS, secrets managers, KMSs, HSMs, and databases instead of replacing them. Vectis is written in Rust and distributed under the Apache-2.0 license.

In Latin, vectis can mean a lever, crowbar, fastening bar, or carrying pole: a simple tool used to move something heavy with controlled force.

What Vectis Does↗

Applications rarely need every property of a sensitive value. One workflow may need to recover it. Another may need only equality search, partial display, or proof of origin.

Vectis keeps the operation the workflow needs and removes unnecessary plaintext exposure.

sensitive value -> [ Vectis ] -> protected representation

The output can be stored, moved, indexed, displayed, verified, or shared under the policy of the selected operation. Each choice preserves a capability and accepts a specific leakage or operational dependency.

Choose the Protection You Need↗

Need	Vectis capability	Preserved operation
Keep an existing format or replace a value	FPE, tokenization, masking	Format, controlled recovery, or partial display
Find or authenticate a protected value	Blind indexes, MACs, commitments	Equality, integrity, or later opening
Protect local data or move it between peers	AEAD encryption, protected messages	Authorized decryption
Prove document origin and integrity	EdDSA + ML-DSA, SLH-DSA	Public verification
Remove a single recovery custodian	Authenticated Shamir Secret Sharing	Threshold reconstruction
Control cryptographic behavior	Signed profiles, permissions, key lifecycle, audit	Explicit policy and evidence

Every row is a tradeoff, not a feature. Advanced Data Protection Techniques works through the leakage, cost, and trust boundary that each one accepts.

Where Vectis Fits↗

Control	Primary responsibility
Identity provider	User and workload identity
TLS	Connection confidentiality and integrity
Secrets manager	Credentials and operational secrets
KMS / HSM	Root-key custody and cryptographic boundaries
Database encryption	Files, pages, backups, or selected fields
DLP	Discovery and movement controls
Vectis	Protection and transformation of sensitive values

Vectis is not a secrets manager, identity provider, database, KMS, HSM, DLP platform, or replacement for TLS. Applications retain their business logic; infrastructure systems retain their existing responsibilities.

Vectis does one narrow job. It composes with the rest.

How It Works↗

application
    |
  HTTP / CLI
    |
    v
[ Vectis + signed profiles ]
    |
    v
protected value -> database / queue / service

A client authenticates and requests a named operation. Vectis checks the signed permission and profile, resolves the allowed key, enforces its lifecycle state, and returns the protected representation.

The profile controls cryptographic behavior. The request supplies data and context, not an arbitrary algorithm selection. Applications decide when a field must be protected and how the result participates in the workflow.

Security Model↗

Vectis keeps policy and cryptographic behavior explicit:

• Signed configuration: routes, peers, permissions, and protection profiles come from operator-signed configuration.
• Controlled profiles: algorithms and parameters are selected by policy, not negotiated independently by each request.
• Key separation: internal keys are derived for distinct purposes, and AEAD binds ciphertext to its operational context.
• Runtime enforcement: permissions and key lifecycle are checked for every operation.
• Verifiable evidence: startup self-tests and hash-chained audit records make failures and security-relevant actions inspectable.
• Attested time: Vectis can attest its local clock on demand with authenticated NTS and verified Roughtime evidence, so audit timestamps do not rest on an unverified system clock.

Hybrid Post-Quantum Cryptography↗

Vectis combines classical and post-quantum algorithms where long-term confidentiality or authenticity matters:

Key establishment  -> XECDH + ML-KEM
Online signatures  -> EdDSA + ML-DSA    both must verify
Offline signatures -> SLH-DSA

The hybrid profile binds both algorithms to the same protocol context. It is a migration strategy, not a claim that post-quantum algorithms replace classical controls everywhere.

Use Cases↗

Payment Data↗

Protect a PAN or account value before it spreads through internal systems.

payment application -> FPE / tokenization -> services and storage

FPE can preserve a constrained numeric format. Tokenization can replace the PAN with a reversible reference. Both reduce where plaintext is available, but the chosen operation still introduces keys, policy, or a token-store dependency.

This design may help isolate payment data and reduce plaintext exposure. Vectis does not determine PCI DSS scope or grant certification; that depends on the complete architecture and its assessment.

Equality Search Without Plaintext↗

Find an encrypted record without storing the comparison value in plaintext.

canonical value -> keyed blind index -> equality lookup

Vectis stores and compares a deterministic keyed digest while the application keeps the protected record. The index preserves exact equality and therefore reveals repeated values. It is not Private Information Retrieval or a general encrypted-query system.

Protected Service Messages↗

Keep a payload protected across a queue or service boundary.

producer -> protected message -> queue / API -> authorized consumer

Vectis binds the payload to registered peer identity and protocol context. An intermediary can carry ciphertext without receiving the plaintext.

Plaintext still exists where the producer protects the message and where the consumer opens it. Those endpoints, their permissions, and plaintext lifetime remain part of the security boundary.

Deploy and Integrate↗

Vectis exposes automation-friendly interfaces and explicit storage choices:

• HTTP API and CLI client.
• OpenAPI contract.
• JSON and YAML output.
• SQLite for local development and labs.
• PostgreSQL for shared, durable storage.
• A Helm chart for Kubernetes deployment.

Adoption does not require an infrastructure rewrite. Vectis can begin with one field, payload, or service boundary and run alongside the existing security and key-management stack.

Why Vectis Exists↗

Vectis exists because of a licensing gap. Format-preserving encryption, reversible tokenization, masking, and encryption as a service have been available in data-protection platforms for years, often as separately licensed features with implementations that cannot be independently inspected or extended.

Vectis is not a fork of anything. It is an independent, from-scratch, open source implementation with its own trust model and deliberately narrow scope. Its design, assumptions, and limits are available for inspection.

Start Small↗

1. Pick one sensitive workflow.
2. Choose the operation that must survive.
3. Define policy and recovery boundaries.
4. Integrate through HTTP or CLI.
5. Measure plaintext reduction and operational cost.

Start with one high-value workflow. Validate its failure modes, observability, and recovery path before expanding.

View the Vectis repository.

---