Security

Trust Signals

Security claims must be verifiable. Private.Me provides measurable evidence across cryptographic implementation, testing rigor, patent protection, and compliance coverage.

Technology Comparison

XorIDA provides information-theoretic security with minimal computational overhead. This table compares XorIDA to alternative privacy-preserving approaches. Performance estimates for FHE, MPC, and TEE are based on published industry benchmarks.

Security Guarantees

Private.Me enforces four mathematical invariants that ensure confidentiality, integrity, and forward secrecy across all ACIs.

1. HMAC Before Reconstruct

Integrity verification MUST complete before reconstruction. Every share carries an HMAC-SHA256 tag computed over the share data. The platform verifies all HMACs before combining shares. If any HMAC fails, reconstruction aborts immediately.

Why it matters: Prevents tampered shares from leaking partial plaintext during failed reconstruction attempts.

2. No Keys

Zero key management. Private.Me uses identity-based cryptography. Entities are identified by Ed25519 public keys (DIDs). Authentication occurs via challenge-response, not shared secrets. No symmetric keys are stored, rotated, or transmitted.

Why it matters: Eliminates key compromise as an attack vector. No keys means no key leakage, no key rotation, no key escrow.

3. Information-Theoretic

Security proven by mathematics, not computational hardness. XorIDA threshold sharing over GF(2) provides perfect secrecy: possessing t-1 shares reveals zero information about the plaintext, regardless of adversarial computational power.

Why it matters: Quantum computers cannot break information-theoretic security. XorIDA-protected payloads remain secure indefinitely.

4. Forward Secrecy

Ephemeral keys per session. Each xLink connection generates fresh X25519 ephemeral key pairs. Session keys derive via ECDH and are used only for that session. Compromise of long-term identity keys does not decrypt past or future sessions.

Why it matters: Even if an attacker obtains an entity's identity key later, previously recorded traffic remains confidential.

Post-Quantum Readiness

Private.Me is quantum-resistant today and will remain secure as quantum computers scale. Our approach combines quantum-proof payload protection with hybrid post-quantum key exchange and signatures.

Quantum-Safe Payload

XorIDA threshold sharing over GF(2) provides information-theoretic security. No amount of computational power — quantum or classical — can break it. Shares reveal zero information about the plaintext without threshold reconstruction.

Hybrid Key Exchange

xLink uses hybrid key exchange combining classical and post-quantum algorithms:

• X25519 (classical ECDH) — 128-bit security level, mature implementation
• ML-KEM-768 (FIPS 203) — Post-quantum key encapsulation, NIST standard

Session keys derive from both exchanges. An attacker must break BOTH algorithms to compromise the session.

Hybrid Signatures

Identity verification uses dual signatures:

• Ed25519 (classical) — 128-bit security level, 64-byte signatures
• ML-DSA-65 (FIPS 204) — Post-quantum digital signatures, NIST standard

Both signatures must verify. This ensures backward compatibility with existing Ed25519 infrastructure while providing quantum resistance.

Zero Developer Changes

Post-quantum algorithms are transparently integrated. Applications using xLink require no code changes, no redeployment, no configuration updates. The upgrade happens at the protocol layer.

Performance Impact

Latency overhead from post-quantum algorithms is negligible:

• ML-KEM-768 encapsulation: <2ms
• ML-DSA-65 signature generation: <3ms
• ML-DSA-65 signature verification: <2ms

Total added latency per connection: <5ms. Unnoticeable in real-world applications.

xLock Authentication

xLock provides push-based authentication without shared secrets. Users approve authentication requests via their device rather than entering passwords or codes.

How It Works

When a service requests authentication:

• Challenge Generation: Server generates a random 32-byte challenge and sends it to the user's device via xLink.
• User Confirmation: Device displays the requesting service identity and asks for approval.
• Signature: User approves → device signs challenge with Ed25519 private key.
• Response: Signed challenge returns to server via xLink.
• Verification: Server verifies signature using user's Ed25519 public key (DID).

Zero Shared Secrets

The server never possesses the user's private key. Authentication proves possession of the private key without transmitting it. No passwords, no OTP seeds, no symmetric keys stored server-side.

Attack surface eliminated: Server breach cannot leak user credentials because the server never had them.

Anti-Push-Bombing Defense

Push bombing attacks overwhelm users with authentication requests until they accidentally approve a malicious one. xLock employs three defenses:

• Challenge Origin Verification: Device verifies the requesting service's DID signature before displaying the prompt.
• Rate Limiting Per Device: Maximum 3 authentication requests per device per 60 seconds. Excess requests are silently dropped.
• User Confirmation Required: No default approval, no timeout approval. User must explicitly tap "Approve."

Single-Use Challenges

Each challenge is cryptographically random and valid for only one authentication attempt. Replay attacks fail because the server rejects reused challenge signatures.

Timing-Safe Verification

Signature verification uses constant-time comparison to prevent timing side-channel attacks. Verification time is independent of where the signature differs from the expected value.

Compliance

Private.Me provides compliance by architecture, not by policy. Our cryptographic design inherently satisfies regulatory requirements for confidentiality, integrity, and access control.

Compliance by Architecture

Traditional compliance requires policy enforcement: employees must follow procedures, configurations must be manually verified, audits check adherence. Private.Me makes non-compliance architecturally impossible:

• Plaintext cannot be stored — XorIDA shares are stored, never plaintext.
• Shares cannot be combined without threshold — cryptographic enforcement, not access control.
• Integrity failures abort reconstruction — HMAC verification is mandatory, not optional.
• Audit logs are immutable — append-only JSONL, cannot be retroactively altered.

Compliance becomes a provable property of the system, not a procedural requirement.

Audit

Private.Me maintains continuous security assurance through dependency audits, cryptographic test vectors, fuzz testing, and coordinated vulnerability disclosure.

Dependency Audit Status

npm audit runs on every CI build. High or critical vulnerabilities block merge. Current status: 0 vulnerabilities (0 low, 0 moderate, 0 high, 0 critical).

Lock files (pnpm-lock.yaml) are committed and verified. No postinstall scripts from third-party packages execute without review.

Cryptographic Test Vectors

All cryptographic primitives include known-answer tests (KATs) from NIST, RFC, and academic sources:

• AES-256-GCM: NIST SP 800-38D test vectors
• HMAC-SHA256: RFC 4231 test vectors
• Ed25519: RFC 8032 test vectors
• X25519: RFC 7748 test vectors
• XorIDA: Internal test vectors covering all threshold configurations (2-of-2, 2-of-3, 3-of-5)

Coverage requirement: 100% line coverage for all crypto modules. No exceptions.

Fuzz Testing

Continuous fuzzing targets:

• Share parsing: Malformed TLV envelopes, invalid magic bytes, corrupted indices
• HMAC verification: Bit flips, truncated tags, replayed shares
• Reconstruction logic: Missing shares, duplicate indices, out-of-order shares

Fuzzing runs for 1 million iterations per module. Failures trigger immediate alerts.

Responsible Disclosure

Security researchers are invited to report vulnerabilities via contact@private.me.

Disclosure Process

• Initial Acknowledgment: 48 hours from report submission
• Severity Assessment: Within 7 days (Critical/High/Medium/Low)
• Remediation Timeline:
  • Critical: 30 days
  • High: 60 days
  • Medium: 90 days
  • Low: Best effort
• Coordinated Disclosure: Public disclosure after patch deployment + 7-day grace period

Scope

In scope:

• Cryptographic vulnerabilities in XorIDA, AES, HMAC, Ed25519, X25519
• Authentication bypass in xLink or xLock
• Share reconstruction failures or integrity violations
• Timing side-channels in crypto operations
• Memory safety issues in crypto modules

Out of scope:

• Denial-of-service attacks (rate limiting is responsibility of deployer)
• Social engineering or phishing
• Physical security testing
• Third-party dependencies (report directly to upstream)

Safe Harbor

Private.Me will not pursue legal action against security researchers who:

• Report vulnerabilities in good faith
• Avoid data exfiltration beyond proof-of-concept
• Do not publicly disclose vulnerabilities before remediation
• Do not perform destructive testing (DoS, data deletion)

We appreciate responsible disclosure and will credit researchers in security advisories (unless anonymity is requested).