Security Model

KayakNet is designed with security as the primary concern. This document describes the security model and guarantees.

Security Layers

┌─────────────────────────────────────────────────┐
│            Application Layer E2E                │
│         (Chat, Marketplace, etc.)               │
├─────────────────────────────────────────────────┤
│           Onion Routing (3 hops)                │
│      X25519 + ChaCha20-Poly1305                 │
├─────────────────────────────────────────────────┤
│          Transport Encryption                   │
│              TLS 1.3                            │
├─────────────────────────────────────────────────┤
│      Traffic Analysis Resistance                │
│   Padding, Mixing, Timing Obfuscation          │
├─────────────────────────────────────────────────┤
│            Anti-Sybil (PoW)                     │
│        Peer Scoring, Rate Limiting              │
└─────────────────────────────────────────────────┘

Cryptographic Primitives

Purpose	Algorithm	Key Size
Identity Keys	Ed25519	256-bit
Key Exchange	X25519	256-bit
Symmetric Encryption	ChaCha20-Poly1305	256-bit
Hashing	BLAKE2b	256-bit
Key Derivation	HKDF-SHA256	-
Signatures	Ed25519	256-bit

Security Guarantees

Confidentiality

• All messages encrypted end-to-end

• Even if network is compromised, content is protected

• Forward secrecy: past messages can't be decrypted

Integrity

• All messages are authenticated (AEAD)

• Tampering is detected and rejected

• Signatures verify sender identity

Anonymity

• Onion routing hides sender/receiver relationship

• Traffic analysis resistance obscures patterns

• No logs are kept by nodes

Availability

• Decentralized architecture resists takedowns

• DHT ensures peer discovery survives node failures

• Multiple bootstrap nodes for redundancy

Threat Model

What We Protect Against

Threat	Mitigation
Eavesdropping	End-to-end encryption
Man-in-the-Middle	Certificate pinning, signatures
Traffic Analysis	Padding, mixing, dummy traffic
Sybil Attacks	Proof-of-Work for new nodes
Eclipse Attacks	Diverse peer selection
Replay Attacks	Nonce tracking
DDoS	Rate limiting, peer scoring

What We Don't Protect Against

Threat	Reason
Global Passive Adversary	Traffic correlation at scale
Endpoint Compromise	If your device is hacked
Rubber Hose Cryptanalysis	Physical coercion
Quantum Computers	(Future: Post-quantum upgrade planned)

Attack Scenarios

Scenario 1: ISP Monitoring

Threat: ISP logs all your traffic Protection:

• TLS hides content

• Onion routing hides destinations

• Traffic padding hides patterns

Scenario 2: Malicious Node

Threat: Attacker runs KayakNet node Protection:

• E2E encryption (can't read content)

• Only sees adjacent hops (can't identify endpoints)

• Peer scoring isolates bad actors

Scenario 3: Network Injection

Threat: Attacker injects fake messages Protection:

• All messages are signed

• Signatures verified before processing

• Invalid messages dropped

Scenario 4: Sybil Attack

Threat: Attacker creates many fake nodes Protection:

• Proof-of-Work required to join

• Peer scoring deprioritizes suspicious nodes

• Eclipse attack prevention in peer selection

Best Practices

For Users

1. Keep software updated - Security patches are important

2. Use strong device security - Full disk encryption

3. Don't reuse identities - Create new node for sensitive activity

4. Verify recipients - Ensure you're talking to who you think

For Node Operators

1. Run latest version - --auto-update

2. Use dedicated machine - Isolate from other services

3. Monitor for anomalies - Watch peer counts, traffic

4. Don't log - Disable any external logging

Security Audits

KayakNet has not yet undergone a formal security audit. If you're a security researcher and would like to audit the code, please contact us.

Responsible Disclosure

If you find a security vulnerability:

1. Do not disclose publicly

2. Email: [email protected] (PGP key available)

3. Include detailed reproduction steps

4. Allow 90 days for fix before disclosure

Known Limitations

1. Metadata - Message timing may leak information

2. Traffic Correlation - Global adversary could correlate

3. Trust in Bootstrap - Initial connection reveals interest

4. Mobile - Battery and network constraints limit protections