# 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: <security@kayaknet.io> (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