LogFlux Security and Encryption

LogFlux implements a zero-knowledge, end-to-end encryption architecture that ensures your log data is protected at every stage of its lifecycle. The service never has access to plaintext data, and all decryption happens client-side.

The service operator has no technical ability to decrypt stored data. Where traditional logging platforms encrypt server-side and control the keys, LogFlux encrypts client-side – keys never leave your infrastructure. Your log data stays private by design, not by policy.

Zero-Knowledge Architecture

LogFlux follows a zero-knowledge encryption model where:

• Clients generate and manage RSA key pairs locally
• Service stores only RSA public keys and encrypted AES keys
• Service never decrypts any data (payloads or AES keys)
• Decryption happens only client-side in LogFlux Clients

Security Flow

1. Setup Phase (One-time)

• Customer generates RSA-4096 key pair locally
• Customer uploads public key to LogFlux Dashboard
• Customer keeps private key secure (never transmitted)

2. Session Establishment

• LogFlux Agent requests handshake with API key
• LogFlux Backend returns customer’s public key + limits
• Agent generates random AES-256 key locally
• Agent encrypts AES key with customer’s public key (RSA-OAEP-SHA256)
• Agent sends encrypted AES key to Backend
• Backend stores encrypted AES key (cannot decrypt it) and returns key_id

3. Log Transmission

• Applications send logs to LogFlux Agent
• Agent encrypts each log with AES-256-GCM + unique nonce
• Agent transmits encrypted logs to Backend over TLS 1.3
• Backend stores encrypted logs with key_id reference

4. Log Analysis

• LogFlux Clients retrieve encrypted logs from Backend
• Clients use customer’s private key to decrypt AES keys
• Clients decrypt log payloads locally for analysis
• Zero-knowledge: Backend never sees plaintext data

Cryptographic Standards

Current Encryption Standard: RSA-OAEP + AES-256-GCM

LogFlux uses a hybrid cryptographic system that exceeds industry standards:

RSA Key Exchange

AES-256-GCM Encryption

Handshake and Encryption Process

The LogFlux Agent handles RSA key exchange to establish secure AES encryption with the LogFlux Backend:

1. Key Pair Generation and Registration

• Customer generates RSA key pair (done once per customer)
• Public key is registered through LogFlux Dashboard

2. Handshake Process

• LogFlux Agent initiates handshake to exchange AES key
• Agent generates random 256-bit AES key
• Agent encrypts AES key with RSA-OAEP-SHA256
• Agent completes handshake and receives key_id for future log entries

3. Log Encryption Flow

• Applications send logs to LogFlux Agent (via SDKs or direct integration)
• LogFlux Agent encrypts log messages with established AES key
• Agent sends encrypted logs to LogFlux Backend
• All encryption/decryption happens on customer infrastructure

What Gets Sent to LogFlux

After completing the handshake, all log entries are sent using multipart/mixed format with the established AES key. Each MIME part carries raw binary ciphertext with metadata in headers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

POST /v1/ingest HTTP/1.1
Authorization: Bearer eu-lf_your_api_key_here
Content-Type: multipart/mixed; boundary=logflux

--logflux
X-LF-Entry-Type: 1
X-LF-Payload-Type: 1
X-LF-Key-ID: 7f8a9b0c-1d2e-3f4a-5b6c-7d8e9f0a1b2c
X-LF-Nonce: YWJjZGVmZ2hpamts
X-LF-Timestamp: 2025-01-20T14:30:45.123Z

<raw binary AES-GCM ciphertext>
--logflux--

MIME Header Fields (per part):

• X-LF-Key-ID: UUID referencing the AES key from handshake completion (required for types 1-6)
• X-LF-Nonce: Base64-encoded 12-byte nonce for AES-GCM initialization (required for types 1-6)
• X-LF-Entry-Type: 1=log (default), 2=metric, 3=trace, 4=event, 5=audit, 6=telemetry, 7=telemetry_managed
• X-LF-Payload-Type: 1=aes256-gcm-gzip-json (default for types 1-6), 2=aes256-gcm-zstd-json, 3=gzip-json (type 7 only), 4=zstd-json (type 7 only)
• X-LF-Timestamp: RFC3339 format (optional, defaults to current time)
• X-LF-Search-Tokens: Comma-separated HMAC tokens for searchable fields (optional)

Part Body: Raw binary ciphertext (no base64 encoding needed, eliminating 33% overhead)

Supports 1-1000 parts per request, unifying single and batch ingestion into one endpoint.

Note: JSON ingestion (application/json) and the standalone batch endpoint (POST /v1/batch) are deprecated. Use multipart/mixed for all new integrations.

Encryption Process Details

Complete Flow

1. RSA Key Pair Generation: Customer generates 4096-bit RSA key pair locally
2. Public Key Registration: Customer uploads public key to LogFlux through Dashboard (one-time setup)
3. Handshake Initiation: Agent authenticates with API key and requests handshake via /v1/handshake/init
4. Public Key Retrieval: LogFlux Backend returns customer’s RSA public key + ingestion limits
5. AES Key Generation: Agent generates random 256-bit AES key locally
6. AES Key Encryption: Agent encrypts AES key with RSA-OAEP-SHA256 using retrieved public key
7. Handshake Completion: Agent sends encrypted AES key via /v1/handshake/complete
8. Session Key Storage: LogFlux Backend stores encrypted AES key AS-IS (never decrypts), returns key_id UUID

Per-Log Encryption (by LogFlux Agent)

1. Log Reception: Agent receives logs from applications via SDKs or direct integration
2. Unique Nonce Generation: Agent generates cryptographically random 12-byte nonce per entry
3. Log Compression: Optional compression of log data before encryption
4. AES-256-GCM Encryption: Agent encrypts compressed log data with session AES key
5. Binary Structure: Agent combines nonce + encrypted data + authentication tag
6. Multipart Transmission: Agent sends raw binary ciphertext via multipart/mixed with metadata in MIME headers (no base64 encoding needed, eliminating 33% overhead)

Key Benefits

• No Key Derivation Overhead: AES keys are pre-generated and cached
• Hardware Acceleration: AES-GCM is optimized on modern processors
• Zero-Knowledge: Service stores encrypted AES keys but cannot decrypt them
• High Performance: Minimal crypto operations per log entry after handshake

Transport Security

HTTPS/TLS Requirements

All communication with LogFlux uses modern TLS:

• Minimum TLS Version: 1.2 (TLS 1.3 preferred)
• Certificate Validation: Required (no self-signed certificates)
• Cipher Suites: Only strong, forward-secret ciphers

API Authentication

LogFlux uses two credential types for different services:

Ingestion (Agent/SDKs use API Keys):

1
2
3

POST https://api.ingest.eu.logflux.io/v1/ingest
Authorization: Bearer eu-lf_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
Content-Type: multipart/mixed; boundary=logflux

Queries (CLI/Grafana use PATs):

1
2

GET https://api.inspect.eu.logflux.io/v1/logs
Authorization: Bearer eu-lf_usr_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

See Authentication Setup for complete details on credential types.

Data Protection

What We Protect

Everything else is encrypted: All actual log data, including log messages, log levels, node names, metadata, and any application-specific information is encrypted within the payload and cannot be read by LogFlux.

Self-Contained Encryption

Each log entry contains everything needed for decryption:

• Nonce: For AES-GCM initialization (unique per entry)
• Encrypted Payload: Your actual log data + authentication tag
• Key ID: References the AES key used for encryption

This means:

• You can decrypt your own data anytime with your RSA private key
• Each log entry is independently encrypted with unique nonces
• No nonce reuse between log entries
• LogFlux cannot decrypt your data (we never have your private key)

Rate Limiting & DDoS Protection

Dynamic Rate Limits

Rate limits are configured per customer and communicated through response headers and discovery endpoints:

• Default: 600 requests/minute per customer
• Burst: 100 requests
• Configurable: Limits can be adjusted based on your subscription plan
• Batch Support: Maximum 1000 entries per batch request

Rate Limit Headers

1
2
3
4

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 599
X-RateLimit-Reset: 1705493445
Retry-After: 30

Request Size Limits

• Max payload size: 1 MiB per log entry (after base64 decoding)
• Max request size: ~1 MiB total HTTP request size
• Max batch size: 1000 entries per batch request

Security Best Practices

1. RSA Private Key Security

1
2
3
4
5
6
7

# Store RSA private keys securely
# Good: Use OS keychain/keystore
security add-generic-password -s "logflux" -a "rsa-private-key" -w "$(cat private_key.pem)"

# Better: Use hardware security modules (HSM)
# Or dedicated key management services
aws kms create-key --description "LogFlux RSA Key"

2. Key Registration and Management

1
2
3

// Register public key through LogFlux Dashboard (one-time setup)
// Store private key securely on client systems
const privateKey = loadFromSecureStorage('logflux-rsa-private-key');

3. Never Log Sensitive Data

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// Good: Log sanitized data
logflux.info(JSON.stringify({
  event: 'user_login',
  user_id: user.id,
  ip: request.ip
}));

// Bad: Never log secrets or PII
logflux.info(JSON.stringify({
  password: user.password,      // NEVER!
  credit_card: user.card_number, // NEVER!
  ssn: user.social_security     // NEVER!
}));

4. Use Different Key Pairs Per Environment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Production - uses production RSA key pair
const prodClient = new LogFluxClient({
  apiKey: process.env.LOGFLUX_API_KEY_PROD,
  privateKeyPath: '/secure/prod-private-key.pem'
});

// Staging - uses staging RSA key pair
const stagingClient = new LogFluxClient({
  apiKey: process.env.LOGFLUX_API_KEY_STAGING,
  privateKeyPath: '/secure/staging-private-key.pem'
});

5. Implement Key Rotation

Regular key rotation improves security:

1. Generate new RSA key pair
2. Register new public key in LogFlux Dashboard
3. Update client applications with new private key
4. New sessions use new key pair automatically
5. Old logs remain readable with previous private key
6. Deactivate old keys after migration period

Compliance & Standards

Cryptographic Standards Support

LogFlux uses industry-standard cryptographic implementations to support your compliance requirements:

• NIST Approved: AES-256-GCM is NIST approved
• FIPS 140-2: Uses Go’s crypto package implementations which are FIPS-validated
• OWASP 2023+: Meets latest cryptographic recommendations
• Common Criteria: Algorithm implementations are certified

Regulatory Compliance Support

LogFlux’s zero-knowledge architecture helps you meet various compliance requirements:

Note: LogFlux is not independently audited for these compliance standards. The platform provides technical capabilities to support your compliance efforts, but you remain responsible for your overall compliance posture.

Advanced Security Features

Future Encryption Modes

The encryption_mode field allows future algorithm upgrades:

Cross-SDK Compatibility

All LogFlux SDKs use identical encryption:

• Data encrypted by Python SDK can be read by Go SDK
• JavaScript encrypted logs work with Java SDK
• Complete interoperability across all platforms

Performance Optimization

Our RSA + AES hybrid system provides excellent performance:

• Session Key Caching: AES keys are cached after handshake (no per-log key derivation)
• Hardware Acceleration: AES-GCM is optimized on modern processors
• Async Processing: Encryption doesn’t block your application
• Batch Support: Efficiently encrypt multiple logs with the same session key

Security Monitoring

What We Monitor

• API key usage patterns
• Rate limit violations
• Invalid payload attempts
• Unusual traffic patterns
• Failed authentication attempts

Security Alerts

Configure alerts for:

• Approaching rate limits
• Repeated authentication failures
• Unusual API usage patterns
• Large payload attempts

Emergency Procedures

Suspected API Key Compromise

1. Immediately: Generate new API key in dashboard
2. Update: Deploy new key to all applications
3. Revoke: Disable compromised key
4. Review: Check logs for unauthorized access

Encryption Secret Compromise

1. Generate: Create new encryption secret
2. Update: Configure applications with new secret
3. Note: Old logs remain encrypted with old secret
4. Future: New logs use new encryption

Support

For security-related questions or to report vulnerabilities:

• Email: security@logflux.io
• Documentation: docs.logflux.io

Remember: LogFlux provides strong encryption for your logs, but security is a shared responsibility. Always use strong secrets, never log sensitive data, and keep your SDKs updated.