> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zkterm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> Security architecture and best practices

## Security Model

zkTerm is designed with security-first principles:

1. **Client-Side Encryption**: All encryption happens in your browser before upload
2. **Zero-Knowledge Proofs**: Verify without revealing sensitive data
3. **Decentralized Storage**: IPFS ensures no single point of failure
4. **On-Chain Verification**: Immutable proof storage on Solana and Starknet

***

## Cryptography

**Encryption Standards**

| Component          | Algorithm   | Details                              |
| ------------------ | ----------- | ------------------------------------ |
| File Encryption    | AES-256-GCM | 256-bit key, unique IV per file      |
| Key Derivation     | PBKDF2      | 200,000 iterations, 32-byte salt     |
| Password Hashing   | bcrypt      | Cost factor 10                       |
| Digital Signatures | Ed25519     | 256-bit keys, client-side generation |
| ZK Proofs          | Groth16     | BN254 curve, \~200 byte proofs       |

**ZK-Friendly Hash Functions**

| Function | Circuit Cost       | Use Case                        |
| -------- | ------------------ | ------------------------------- |
| Poseidon | \~300 constraints  | Most ZK operations, commitments |
| Pedersen | \~1000 constraints | Homomorphic commitments         |
| MiMC     | \~500 constraints  | Alternative ZK hash             |

Note: Traditional SHA-256 requires \~25,000 constraints in ZK circuits, making ZK-friendly alternatives essential.

**Proof Systems**

1. **Groth16 (zkStorage)**: Trusted setup via Powers of Tau, \~100ms verification
2. **STARK (zkID)**: Transparent setup, no trusted ceremony needed

***

## zkToolkit Security

The `@zkterm/zktoolkit` package provides 10 cryptographic modules:

1. **hash**: Poseidon, Pedersen, MiMC hash functions
2. **commit**: Pedersen commitments (hiding + binding properties)
3. **nullifier**: Double-spend prevention via Poseidon(secret, scope)
4. **range**: Range proofs using bit decomposition
5. **sign**: EdDSA over Baby Jubjub curve
6. **merkle**: Merkle tree construction and proofs
7. **field**: BN254 prime field arithmetic
8. **ec**: Baby Jubjub elliptic curve operations
9. **shamir**: Secret sharing (k-of-n threshold)
10. **proof**: Groth16 proof generation

***

## Threat Model

**Protected Against**

* Man-in-the-Middle: TLS encryption + client-side crypto
* Server Compromise: Server never sees passwords or private keys
* Replay Attacks: Nonce-based signatures
* Brute Force: bcrypt slow hashing + rate limiting
* Data Tampering: IPFS content addressing + SHA-256 checksums
* Double Spend: Nullifier sets with Poseidon hashing

**Limitations**

* Quantum Computers: Ed25519 is vulnerable (post-quantum research in progress)
* Client Malware: If your device is compromised, keys can be extracted
* Social Engineering: Phishing attacks targeting users
* Lost Passwords: No password recovery by design (user controls keys)

***

## Best Practices for Users

**Password Security**

1. Use 16+ character passwords
2. Include numbers, symbols, uppercase letters
3. Never reuse passwords across services
4. Use a password manager
5. No password recovery exists - store passwords safely

**Key Management**

1. Export private keys to secure offline location
2. Never share private keys with anyone
3. Store backups on encrypted USB or hardware wallet
4. Consider hardware wallet for high-value operations

**File Storage**

1. Verify checksums after downloading files
2. Keep backup of important file IDs
3. Use unique passwords for each file
4. Never upload sensitive data without encryption enabled

**Blockchain Operations**

1. Verify transaction details before signing
2. Use hardware wallet for large amounts
3. Double-check contract addresses
4. Monitor gas prices before transactions

***

## Best Practices for Developers

**API Security**

```typescript theme={null}
// Always use HTTPS and include credentials
const response = await fetch('/api/endpoint', {
  credentials: 'include',
  headers: {
    'Content-Type': 'application/json'
  }
});

// Validate all inputs
if (!password || password.length < 12) {
  throw new Error('Password must be at least 12 characters');
}
```

**Error Handling**

```typescript theme={null}
// Don't expose sensitive error details to users
try {
  await zkStorage.download(fileId, password);
} catch (error) {
  // Log full error server-side only
  console.error('[Server]', error);
  // Return generic message to user
  throw new Error('Decryption failed');
}
```

**Rate Limiting**

```typescript theme={null}
// Implement exponential backoff
const delay = Math.min(1000 * Math.pow(2, attempts), 30000);
await new Promise(resolve => setTimeout(resolve, delay));
```

***

## Memory Safety

zkTerm implements secure memory handling:

1. **Private Key Zeroization**: Keys are zeroed from memory after use
2. **ArrayBuffer Usage**: Sensitive data stored in ArrayBuffer (can be zeroed)
3. **Wallet Mutex Locking**: Prevents concurrent transactions on same wallet
4. **Session Isolation**: Express sessions with PostgreSQL storage

***

## Smart Contract Security

**Starknet zkID Registry**

The ZkIDProofRegistry Cairo contract stores proof hashes on-chain:

* Immutable proof storage (write-once)
* Owner-only verification
* Gas-optimized felt252 operations
* Deployed on Starknet Sepolia (mainnet planned)

**Solana Verification**

Native Ed25519 signature verification:

* Uses Solana's built-in ed25519 program
* Transaction memo for proof anchoring
* Deployed on Solana Mainnet

***

## Incident Response

If you discover a security vulnerability:

1. Do NOT disclose publicly
2. Report via GitHub security advisories or X DM [@zkterm](https://x.com/zkterm)
3. Include steps to reproduce and impact assessment
4. We will respond within 48 hours
5. Credit given to researchers (with permission)

***

## Compliance

* **Privacy by Design**: No personal data stored on servers
* **Client-Side Encryption**: User data encrypted before leaving browser
* **Decentralized Storage**: Files stored on IPFS, not centralized servers
* **User-Controlled Keys**: Only users can decrypt their data

***

## Stay Updated

Follow [@zkterm](https://x.com/zkterm) on X for security updates.

Report issues at [github.com/zkterm](https://github.com/zkterm).