> For the complete documentation index, see [llms.txt](https://docs.kayaknet.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kayaknet.io/security/security.md).

# 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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kayaknet.io/security/security.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.