What encryption does Opsalis use?

Opsalis uses ECDH (Elliptic Curve Diffie-Hellman) on the P-256 curve for key exchange, and AES-256-GCM for authenticated encryption of all API request and response data. Each message uses a unique random IV.

Can Opsalis read my API data?

No. Opsalis is zero-knowledge by design. The platform coordinates routing and billing but never holds decryption keys. It only sees encrypted ciphertext. Even if the platform were fully compromised, no API data would be exposed.

Is this the same as TLS?

No. TLS encrypts data in transit between hops, but any intermediary that terminates TLS sees plaintext. Opsalis provides end-to-end application-layer encryption where data is encrypted by the consumer's node and only decryptable by the owner's node. No intermediary — including Opsalis — can read the data.

Do I need to change my API code for encryption?

No. The Opsalis wrapper handles all encryption and decryption transparently. Your API receives plaintext requests and returns plaintext responses. The wrapper encrypts outbound data and decrypts inbound data automatically.

Zero-Knowledge API Security

End-to-End Encryption Architecture

ECDH key exchange establishes a shared secret. All data is AES-256-GCM encrypted. The platform coordinates routing and billing but never holds decryption keys.

Why Zero-Knowledge Matters

In traditional API marketplaces, the platform sees every request and every response. Your API keys, user data, financial records, and proprietary algorithms all flow through someone else's infrastructure in plaintext. You're trusting the marketplace operator with your most sensitive data.

Opsalis eliminates this trust requirement. Using Elliptic Curve Diffie-Hellman (ECDH) key exchange, consumer and API owner establish a shared secret that the platform never knows. Every API call — parameters, headers, response body — is encrypted with AES-256-GCM before it leaves the sender. The platform routes encrypted ciphertext and records billing events, but is cryptographically unable to read the data.

This is not just encryption in transit (TLS). This is end-to-end encryption where the application-layer data is encrypted by the consumer's node and only decryptable by the owner's node. Even if the platform were compromised, no API data would be exposed.

Live Demo — Encrypted vs. Decrypted

Make an Encrypted API Call

API Endpoint

Request Payload (plaintext)

Encryption

ECDH P-256 + AES-256-GCM
Per-session IV, authenticated encryption

Click "Run Encrypted Call" to see the difference between what the platform sees (encrypted ciphertext) and what the consumer/owner see (plaintext).

Code Samples

# API call — encryption is handled automatically by the consumer wrapper
# The wrapper encrypts your payload before sending via P2P
$ curl -X POST https://opsalis.com/api/demo/api/bb-webhook-receiver \
  -H "Content-Type: application/json" \
  -H "X-Consumer-Key: demo-public-key-2026" \
  -d '{
    "action": "getStatus",
    "apiKey": "sk_live_secret_12345"
  }'

# What the platform sees: encrypted ciphertext
# What you receive: plaintext JSON response
# The wrapper handles encrypt/decrypt transparently

// JavaScript — encryption is transparent to the caller
// The consumer wrapper handles ECDH + AES-256-GCM automatically

const response = await fetch('https://opsalis.com/api/demo/api/bb-webhook-receiver', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Consumer-Key': 'demo-public-key-2026'
  },
  body: JSON.stringify({
    action: 'getStatus',
    apiKey: 'sk_live_secret_12345',
    userId: 'user_987654'
  })
});

// Response is already decrypted by the wrapper
const data = await response.json();
console.log('Decrypted response:', data);

// Under the hood:
// 1. ECDH shared secret derived from subscription keys
// 2. Request body → AES-256-GCM encrypt → ciphertext sent via P2P
// 3. Owner decrypts → processes → encrypts response
// 4. Consumer decrypts response → returns plaintext to you

# Python — encryption is transparent
# The consumer wrapper handles all cryptography
import requests

response = requests.post(
    'https://opsalis.com/api/demo/api/bb-webhook-receiver',
    headers={
        'Content-Type': 'application/json',
        'X-Consumer-Key': 'demo-public-key-2026'
    },
    json={
        'action': 'getStatus',
        'apiKey': 'sk_live_secret_12345',
        'userId': 'user_987654'
    }
)

# Response is already decrypted
data = response.json()
print(f"Decrypted: {data}")

# Encryption details:
#   Key exchange: ECDH P-256 (secp256r1)
#   Cipher: AES-256-GCM
#   IV: Random 12 bytes per message
#   Auth tag: 16 bytes (128-bit)

Self-Host with Zero-Knowledge Security

Pull the Opsalis Docker Container

The control center generates ECDH key pairs on first startup. Keys never leave your hardware.

$ docker pull opsalis/control-center:latest
$ docker run -d --name opsalis -p 3000:3000 opsalis/control-center:latest

Key Exchange Happens Automatically

When a consumer subscribes to your API, the two nodes exchange ECDH public keys and derive a shared secret. This happens once at subscription time — no manual configuration needed.

Every Call Is Encrypted Transparently

API consumers call your endpoint normally. The wrapper encrypts outbound requests and decrypts inbound responses automatically. No code changes to your API or your consumers' code.

# Your API code is unchanged — the wrapper handles crypto
# Consumers call your API normally — their wrapper encrypts/decrypts
# The platform sees only: AES-256-GCM(payload, shared_secret)

Verify Zero-Knowledge

Audit the P2P traffic yourself. Run a packet capture on the P2P port and verify that only encrypted ciphertext is transmitted. The platform has no key material.

$ tcpdump -i eth0 -X port 3001 | head -50
# You'll see only encrypted binary data — no plaintext API content